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FOREWORD 

The  life  cycle  support  of  th**  ever  increasing  number  of  computer 
systems  embedded  in  weapon  systems  is  a  major  challenge  to  the  Air 
Force  Logistics  Command.  With  continued  operational  and  support 
emphasis  on  weapon  performance  and  responsiveness  to  a  dynamic 
mission  environment,  significant  enhancement  of  support 
capabilities  for  all  categories  of  embedded  computer  systems  is 
required.  This  report,  Long  Range  Plan  for  Embedded  Computer 
Systems  Support  (Volume  11),  and  Executive  Overview  (Volume  I) 
contain  recommendations  for  acquiring  such  capabilities. 

This  volume  is  one  of  two  individually  bound  volumes  that  con¬ 
stitute  the  Phase  111  Final  Report,  Study  of  Embedded  Computer 
Systems  Support,  for  Contract  F33600-79-C-0540,CDRL.  05 A.  The 
efforts  and  analyses  reported  in  these  volumes  were  sponsored  by 
AFLC/LO  and  cover  a  reporting  period  from  December  1980 
through  August  1981. 
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1.  LONG  RANGE  ECS  SUPPORT  PLAN 


Over  the  past  ten  years,  technological  advances  have  occurred  in  virtually  all  aspects  of 
weapon  system  functions.  This  is  particularly  evident  in  sophisticated  weapon  systems  that 
encompass  embedded  computer  systems  as  an  essential  and  integral  part  of  system  structure. 
This  trend  is  expected  to  continue  and  is  forecast  to  accelerate  in  the  future  with  Very  High 
Speed  Integrated  Circuits  (VHSIC),  fiber  optics,  microprocessors— just  to  name  a  few  of  the 
rapidly  changing  technologies  being  embodied  in  weapon  systems  and  requiring  support  by  the 
Logistics  Command.  This  plan  addresses  the  management  and  technical  support  of  computer 
systems  embedded  in  weapon  systems  and  highlights  the  significant  differences  from  the  tradi¬ 
tional  Air  Force  Logistics  Command’s  classical  role  in  providing  wholesale  logistics  support  to 
operational  commands  by  ensuring  that  weapon  systems  are  operational  through  buying,  sup¬ 
plying,  transporting,  and  maintaining  the  system  and  their  components. 

1.1  PURPOSE  AND  SCOPE 

The  purpose  of  this  Long  Range  ECS  Support  Plan  is  to  project  the  1990  ECS  support 
environment  and  based  on  that  forecast  to  describe  an  approach  and  outline  the  administrative 
and  programmatic  initiatives  necessary  to  achieve,  over  the  next  ten  years,  a  mission  responsive 
ECS  support  posture.  The  plar  encompasses  the  five  categories  of  ECS  identified  in  AFLCR 
800-21  and  uses  the  support  concepts  described  therein  as  a  starting  point.  The  plan  also  draws 
upon  the  current  posture  assessments  and  associated  deficiencies  identified  in  the  nine-volume 
final  report  resulting  from  the  precursor  Phase  II  Study  of  Embedded  Computer  Systems  Sup¬ 
port  (October  1980),  This  plan  outlines  the  HQAFLC  management  and  technical  activities 
required  to  establish  a  command-wide  ECS  support  posture  and  provides  methodology  includ¬ 
ing  resource  estimates  and  schedules  for  implementing  the  plan.  An  overview  of  the  long  range 
plan  components  and  their  relationship  is  shown  in  Figure  1-1. 

1.2  POSTULATED  1990  ECS  SUPPORT  ENVIRONMENT 

An  accurate  prognostication  of  the  future  ir  ~f  <-nurse  impossible,  but  a  consensus  of  recent 
government  and  industry  studies  and  analysis  indicates  that  a  realistic  projection  of  the  future 
ECS  support  environment  will  certainly  include  continuation  of  a  rapidly  evolving  and  expand¬ 
ing  use  of  technology,  an  ever-increasing  enemy  threat  and  corresponding  demand  for  mission 
responsiveness,  and  continuing  competition  for  scarce  ECS  support  resources.  A  typical  exam¬ 
ple  of  such  a  forecast  is  a  recent  “DOD  Digital  Data  Processing  Study— a  Ten  Year  Forecast” 
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Figure  1-1.  Overview  of  Long  Range  ECS  Support  Plan  Components 
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which  was  performed  by  an  industry  team  under  the  auspices  of  the  Requirements  Committee, 
Government  Division,  Electronics  Industries  Association  (EIA).  The  industry  team  consisted  of 
representatives  from  Control  Data  Corporation,  IBM,  Intel,  ROLM  Corporation,  and  TRW. 

The  study  team  used  multiple  sources  to  obtain  and  verify  information  including  DOD 
budget  data;  congressional  testimonies;  over  40  personal  interviews  with  experts  in  industry, 
DOD,  congressional  staff,  OMB,  and  GSA:  periodicals;  industry  market  research  publications 
including  Frost  and  Sullivan,  DMS,  Quantum,  et  al.;  and  published  data  from  several  govern¬ 
ment  sources  including  OMB,  GSA  and  GAO.  A  few  of  the  highlights  contained  in  the  executive 
summary  of  the  study  report  are  shown  in  Table  1-1. ^ 

Within  the  DOD  and  Air  Force  the  pressure  for  “Better-faster-more  with  less”  will  con¬ 
tinue.  Consequently,  the  foreseeable  and  postulated  future  ECS  support  environment  is 
expected  to  be  characterized  as  follows: 

•  Continued  world  tension  with  alignment/realignment  of  national 
interests, 

•  Multiservice  and  multinatio.i  use  of  ECS  and  ECS  support  systems, 

•  Increasing  complex  weapon  and  support  systems, 

•  Increased  pressure  for  interoperability  and  standardization  of  ECS  and 
ECS  support  systems, 

•  Increased  vulnerability  of  ECS  to  enemy  countermeasures, 

•  Extension  of  ECS  support  systems  to  theater  and  flightline  for  combat 
mission  needs, 

•  Increased  competition  for  engineering  and  scientific  disciplines  as  well  as 
support  funds, 

•  Rapidly  increasing  ECS  workload,  and 

•  Increased  need  for  ECS  management  and  technical  training. 

1.3  ECS  SUPPORT  OBJECTIVES  AND  CONCEPTS  FOR  1990 
1.3.1  ECS  Support  Objectives 

The  requirement  to  provide  for  embedded  computer  resources  stems  from  the  traditional 
logistics  weapon  system  support  role  of  buying,  supplying,  transporting,  and  maintaining 


^Unless  otherwise  stated,  all  dollars  are  current  in  billions. 
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Table  l-l .  DOl)  Digital  Data  Processing  Study:  A  Ten-Year  Forecast 


•  “Embedded  computers  are  defined  in  the  study  as  specially  designed,  for 
example,  designed  to  satisfy  MIL-Specs,  and  are  acquired  as  part  of  a 
total  weapons  package,  thus  “embedded”  in  a  weapons  system.  It  is  not 
generally  recognized  by  most  personnel  in  the  computer  field  that  embed¬ 
ded  computers  presently  represent  over  60  percent  of  the  DOD  computer 
budget,  and  the  percentage  is  projected  to  increase  to  approximately  75 
percent  by  1985  and  83  percent  by  1990.  Microprocessors  will  have  an 
ever-increasing  influence  in  the  embedded  area;  much  more  so  than  in 
the  ADP  area.” 

•  “It  is  forecast  that  in  the  coming  decade,  nearly  every  weapon  system  will 
have  an  embedded  computer  (or  computers)  somewhere  in  its  control 
subsystem  and/or  C^I  subsystem.” 

•  “Single  chip  microprocessors  capable  of  performing  a  million  instruc¬ 
tions  a  second  (1MIP)  are  forecast  to  be  developed  during  the  early 
1980’s.” 

•  “Defense  Electronics  will  increase  from  $20.1  in  FY80  to  $75.7  in  FY90. 
Defense  computers  will  increase  from  $6.7  in  FY80  to  $45.8  in 
FY90 — from  33  percent  of  Defense  Electronics  in  FY80  to  60  percent  by 
FY90." 

•  “Software  and  Services  will  increase  from  $4.6  in  FY80  to  $37.2  in 
FY90 — from  69  percent  of  the  total  Defense  computer  expenditures  in 
FY80  to  81  percent  in  FY90.” 

•  “Software  hourly  rates  have  nearly  tripled  since  1965  and  are  projected 
to  be  over  five  times  the  1965  base  by  1990.  However,  the  cost  of  com¬ 
puter  hardware  is  decreasing  dramatically.  By  1990,  the  cost  of  large 
mainframe  computers  and  the  cost  of  mini/macro  computers  are  pro¬ 
jected  to  be  one-fifth  and  one-tenth  respectively  of  the  1965  base.” 

•  “In  1955,  there  were  approximately  1000  computers  and  10,000  pro¬ 
grammers,  a  1:10  ratio  in  the  U.S.  Today,  there  are  approximately 
900,000  computers  and  240,000  programmers,  a  37:10  ratio.  Even  with 
productivity  improvements,  the  shortage  of  qualified  software  personnel 
will  not  end;  software  costs  will  continue  to  rapidly  escalate.” 

•  “During  the  1980’s: 

•  The  total  DOD  budget  will  increase  2.8  times, 

•  The  DOD  Electronics  budget  will  increase  3.8  times, 

•  The  DOD  Computer  budget  will  increase  6.8  times. 

•  The  DOD  Software  budget  will  increase  8.1  times." 
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systems.  However,  the  management  and  technical  support  of  ECS,  and  particularly  the 
reprogramming  of  embedded  computer  software,  is  an  engineering  intensive  activity.  The  actual 
programming/coding  is  a  relatively  small  part  of  the  ECS  change  process.  The  system  and 
digital  engineering  required  for  problem  analysis/isolation/definition  along  with  the  engineering 
design  of  proposed  problem  or  enhancement  solutions  and  verification/validation  testing  is 
usually  by  far  the  most  crit.al  resource  in  terms  of  skill,  equipment,  and  schedule.  A  generic 
description  of  the  ECS  software  change  process  is  shown  in  Figure  1-2.  Extensive  use  of  both 
engineering  and  scientific  disciplines  is  also  required  for  the  acquisition  of  ECS  support  tools 
and  equipment  as  well  as  the  operation  of  ECS  support  facilities. 

The  current  Statement  of  Need  (SON)/Missi.on  Element  Need  Analysis  (MENA)  addresses 
the  practice  of  acquiring  system  specific  or  point  design  ECS  support  facilities  (tools,  equip¬ 
ment,  and  skills)  and  the  need  for  increased  standardization  and  automation  of  ECS  support 
processes  and  procedures,  along  with  increased  integration  and  sharing  of  critical  ECS  support 
resources.  This  long  range  ECS  support  plan,  which  supports  the  SON/MENA,  is  based  upon  a 
set  of  twelve  postulated  ECS  support  objectives.  These  objectives,  which  are  closely  related, 
were  compiled  from  a  longer  list  of  more  specific  problem/deficiency  objectives  and  are, 
therefore,  not  necessarily  aimed  at  any  one  ECS  support  requirement  or  current/projected  defi¬ 
ciency  They  are  applicable  to  the  entire  l:fe  cycle  ECS  acquisition  and  support  process  and 
extend  across  the  five  ECS  categories.* 

•  Acquire  and  maintain  a  flexible  technical  support  base  and  establish  data 
flow  to  rapidly  respond  to  ECS  combat  needs. 

•  Provide  efficient  and  effect's e  ECS  lite  cycle  management  and  system 
engineering  support. 

•  Promote  efficient,  effective,  and  timely  use  of  interservice  as  welt  as 
inter-  and  intracommand  ECS  support  resources. 

•  Acquire  and  maintain  quality  ECS  and  ECS  support  systems. 

•  Ensure  currency  and  survivability  of  ECS  support  systems. 

•  i  cquire  and  maintain  ECS  technology  and  intelligence  bases  and  provide 
fu.  intercommand  and  interservice  exchange  and  use  of  data. 

•  Ensure  an  attractive  and  competitive  ECS  management  and  engineering 
career  field. 

•  Minimize  critical  organic  ECS  engineering,  scientific  and  technical  skill 
needi. 

^Appendix  A  contains  an  elaboration  of  each  of  the  objectives. 
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•  Provide  for  efficient  and  effective  training  and  cross-training  in  ECS 
engineering,  scientific,  and  technical  skills. 

•  Optimize  the  compi, mentary  strengths  of  organic  and  contractor  skills. 

•  Accomplish  efficient  and  effective  ECS  support  cost  estimating,  tracking 
and  accounting. 

•  Influence  the  proliferation  of  ECS  and  ECS  support  systems. 

1.3.2  ECS  Support  Concepts 

Support  concepts  for  each  of  the  five  ECS  categories  as  currently  documented  in  AFLCR 
800-21  have  evolved  over  a  period  of  time.  While  these  individual  category  concepts  are  still  in 
various  stages  of  implementation,  the  technology  implemented  in  future  weapon  system  designs 
is  expected  to  blur  the  currently  perceived  distinction  between  the  five  categories,  particularly 
between  C-E,  EW,  and  OFP.  Closely  coupled  with  the  individual  category  support  concepts, 
whatever  their  distinction  or  numbers,  are  ECS  support  concepts  which  are  intended  to  apply 
within  each  category  as  well  as  across  the  categories.  They  address  ECS  support  in  the  aggregate 
and  provide  the  framework  for  achieving  the  previously  stated  objectives  and  acquiring  the 
overall  ECS  support  capabilities  required  over  ihe  next  decade.  Table  1-2  shows  the  five  ECS 
categories  and  the  current  support  concept  described  in  AFLCR  800-21 .  It  also  shows  postulated 
improvements/alternatives  to  these  concepts  along  with  the  closely  related  overall  ECS  support 
concepts  postulated  as  a  basis  for  the  long  range  ECS  support  plan. 

1.4  RELATIONSHIP  TO  OTHER  ECS  SUPPORT  PLAN 

The  long  range  ECS  support  plan  is  consistent  with  existing  and  projected  Department  of 
Defense  and  Air  Force  directives,  regulations,  policy,  and  guidance  for  acquisition  and  support 
of  computer  resources.  For  example,  it  is  consistent  with  Department  of  Defense  Directives 
5000.1,  “Major  Systems  Acquisition,”  5000.2  “Major  Systems  Acquisition  Process,”  and 
5000.29  “Management  of  Computer  Resources  in  Major  Defense  Systems;”  it  is  complemen¬ 
tary  to  Air  Force  Regulation  800-14,  '’oiume  I,  “Management  of  Computer  Resources  in 
Systems”  and  Volume  II,  “Acquisition  and  Support  Procedures  for  Computer  Resource  in 
Systems;”  Air  Force  Regulation  800-28  “Air  Force  Policy  on  Avionics  Acquisition  and  Sup¬ 
port,”  Air  Force  Logistics  Command  Regulation  800-21  “Management  and  Support  Pro¬ 
cedures  for  Computer  Resources  used  in  Defense  Systems,”  and  the  recent  Air  Force  policy 
memorandum  on  “Standardization  of  Embedded  Computer  Resources.”  It  is  both  consistent 
with  and  complementary  to  various  other  AFLC  and  AFSC  studies  and  ongoing  activities  such 
as  the  “Computer  Technology  Forecast  and  Weapon  System  Impact  Study”  (COMTEC-2000), 
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Table  1-2.  Postulated  1990  ECS  Support  Concepts  (Concluded) 
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the  “Embedded  Computer  Resources  Support  Planning  for  the  1 980’s  (ESP-80),  and  the  United 
States  Air  Force  Avionics  Master  Plan. 


The  long  range  ECS  support  plan  is  designed  for  use  by  planners  and  implementers  respon¬ 
sible  for  current  and  future  AFLC  life  cycle  ECS  support  activities  as  well  as  overall  guidance 
and  direction  for  the  aggregate  of  ECS  support  over  the  long  term.  As  such,  it  serves  as  guidance 
for  development  and  implementation  of  plans  for  the  separate  categories  and  for  standardiza¬ 
tion  of  support  elements  across  categories. 

1.5  PROJECTED  1990  ECS  SUPPORT  SCENARIO 

The  following  scenario  assumes  that  the  administrative  and  programmatic  initiatives, 
presented  in  Volume  1  and  detailed  in  subsequent  sections  of  this  volume,  have  been  imple¬ 
mented.  It  also  assumes  that  normal  logistics  planning  appropriate  to  weapon  system  acquisition 
and  support  has  or  is  being  conducted.  Figure  1-3  summarizes  the  various  components  discussed 
in  this  section.  A  detailed  discussion  of  ECS  support  requirements  is  presented  in  Section  2  of 
this  volume  and  by  ECS  category  in  the  Phase  II  report  (Volumes  111  through  VII). 

AFLC  ECS  support  activities  for  a  new  embedded  computer  system  begin  in  earnest  with 
formation  of  the  Computer  Resources  Working  Group  (CRWG).  Writing  the  Computer 
Resources  Integrated  Support  Plan  (CRISP)  and  detailed  definition  of  support  system  require¬ 
ments  proceeds  quickly  since  AFLC  will  have  developed  model  CRISP’s,  established  support 
system  data  bases,  and  defined  the  AFLC  position  on  support  system  requirements  for  each 
general  type  of  system  containing  ECS.  CRWG  meetings  and  CRISP  reviews  will  be  held  by 
video  teleconferencing  to  access  necessary  expertise,  ensure  coordination  with  other  weapon 
system  support  elements,  and  minimize  travel  costs.  Prior  to  PMRT,  AFLC  will  perform  an 
Independent  Verification  and  Validation  (IV&V)  of  the  ECS  and  its  supporting  documentation, 
which  will  significantly  aid  AFLC  in  improving  product  quality  at  transition,  training,  and  in  the 
acquisition  and  use  of  the  new  support  system. 

Definition  of  the  Operational/Support  Configuration  Management  Procedures  (O/S 
CMP)  will  be  facilitated  by  use  of  AFLC  developed  model  O/S  CMP’s  and  standardized  config¬ 
uration  management  systems  as  a  basis  for  initial  drafts.  Reviews  involving  the  various  user  and 
support  agencies  will  also  be  via  video  teleconferencing.  New  weapon  systems,  while  more  com¬ 
plex  than  most  current  systems,  will  be  easier  to  support  due  to  AFLC  initiatives  to  improve 
system  design  for  supportability  and  testability  along  with  increased  interface  control  and  stan¬ 
dardization  of  languages  and  instruction  set  architectures.  Support  systems  will  be  modular  and 
reconfigurable,  and  will  utilize  standard  models  (e.g.,  for  such  functions  as  aircraft,  environ¬ 
mental,  and  terrain  simulations).  Increased  weapon  system  and  support  system  standardization 
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will  allow  support  dollars  to  be  invested  in  improving  the  quality  of  the  support  systems  and  to 
increase  productivity. 

After  Program  Management  Responsibility  Transfer  (PMRT),  automated  standardized 
tools  will  aid  in  configuration  management  and  documentation  as  well  as  in  the  actual  ECS  and 
software  change  and  test  process.  A  copy  of  updated  software  and  its  supporting  documentation 
will  be  transmitted  after  change  certification  via  the  AFLC  ECS  support  network  to  operational 
units  and  other  users  and  to  the  designated  AFLC  software  repository.  Support  in  solving  par¬ 
ticularly  difficult  ECS  technical  problems  will  be  sought  from  the  appropriate  AFLC  skill  con¬ 
centrations.  These  skill  centers  will  also  assist  the  ALC’s  in  dealing  with  the  new  technology 
embodied  in  weapon  systems,  major  weapon  system  modification  programs  affecting  ECS,  and 
in  developing  standard  support  systems.  The  ability  to  video-conference  with  AFLC  and  USAF 
specialists,  and  increased  usage  of  automated  tools  will  aid  in  increasing  productivity  of 
engineering  and  technical  personnel.  New  and  improved  professional  education  and  training 
programs,  again  employing  video  teleconferencing  in  lieu  of  costly  and  inconvenient  TDY, 
along  with  ECS  career  progression  incentives  will  assist  AFLC  in  obtaining  adequate  numbers  of 
trained  engineers,  programmers,  and  technicians. 

AFLC  definition  of  intelligence  support  roles  and  responsibilities  and  enhancement  of  sup¬ 
port  facilities  will  allow  AFLC  to  perform  preemptive  engineering  and  increase  responsiveness 
to  a  dynamic  mission  environment.  Automation  and  standardization  of  ECS  support  tools, 
modular  system  integration  facilities  and  ECS  support  networks  will  alleviate  many  of  the  diffi¬ 
culties  of  integrating  subsystems  managed  at  geographically  separate  locations. 
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Embedded  computer  system  support  requirements  and  current  deficiencies  were  examined 
in  detail  during  the  first  two  phases  of  the  study  effort  and  an  overview  is  provided  here  primar¬ 
ily  for  emphasis  and  completeness.  Software  suppt  rt  requirements  were  emphasized  and  the 
requirements  common  to  all  ECS  categories,  and  those  requirements  unique  to  a  particular 
category  were  identified.  These  requirements,  documented  in  Volume  III  through  VII  in  the 
Phase  II  Report  and  summarized  in  Table  2-1,  are  expected  to  continue  for  the  foreseeable 
future.  For  easy  reference,  additional  detail  on  these  current  ECS  support  requirements  is  pro¬ 
vided  in  Appendix  B. 

The  current  ECS  support  posture,  also  documented  in  the  Phase  II  Report,  is  an  assessment 
of  the  degree  to  which  the  support  requirements  are  being  met.  Many  of  the  support  deficiencies 
identified  by  category  in  the  Phase  II  Report  are  similar  or  common  to  several  or  all  categories 
of  ECS  systems.  The  various  current  support  deficiencies  are  grouped  according  to  their  general 
type,  and  are  presented  in  summary  form  in  Tables  2-2  through  2-5.  Also  shown  are  the  affected 
categories  along  with  recommended  corrective  actions  for  each  deficiency.  The  corrective 
actions  are  embodied  in  the  vaiious  recommended  administrative  and  programmatic  initiatives 
presented  in  Sections  3,  4,  and  5. 

2.1  FUTURE  ECS  SUPPORT  REQUIREMENTS/PROBLEMS 

The  trend  toward  more  weapon  systems  encompassing  embedded  computer  systems  as  an 
essential  part  of  system  structure  is  expected  to  increase  the  AFLC  role  in  direct  mission  sup¬ 
port.  With  weapon  system  performance  and  combat  readiness  directly  coupled  to  ECS  support, 
new  support  requirements/problems  which  were  not  addressed  in  the  Phase  II  Report  are 
expected  to  surface.  One  such  example,  not  yet  definitized  as  an  established  support  require¬ 
ment,  is  the  multiuse  system  or  subsystem  containing  an  ECS.  The  PAVE  TACK  system  which 
is  u^ed  on  both  the  F-lll  and  F-4  is  a  :ase  in  point.  Other  systems  under  development  or  being 
considered  for  development  such  as  JTIDS,  LANTIRN,  and  GPS  introduce  situations  where  a 
weapon  system  contains  ECS  systems/subsystems  which  arc  not  under  the  direct  control  of  the 
weapdn  system  manager. 

In  addition,  planned  product  improvements  as  well  as  the  use  of  aircraft  for  missions  other 
than  originally  designed  have  changed  and  will  continue  to  change  support  requirements  for 
ECS  because  different  configurations  of  the  ECS  are  being  supported  with  different  demands  on 
resources  as  functions  of  time  or  criticality.  For  example,  the  F-16’s  original  design  role  is  being 
expanded  to  include  both  air-to-air  and  air-to-ground  capabilities.  The  F-1 5  Strike  Eagle  would 
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Table  2-1.  ECS  Support  Requirements 


Common  to  All  ECS  Categories 

Life  Cycle 

Management 
System  Engineering 
T  raining 

Pre-PMRT  ECS  Support 

Support  System  Requirements 
Suppo rtability  Design  Criteria 

Post- PM RT  ECS  Support 
ECS  Change 

Change  Analysis  and  Specification 
Engineering  Development  and  Unit  Test 
System  Integration  and  Test 
Change  Documentation 
Certification  and  Distribution 

Category  Unique 

Post-PMRT  ECS  Support 

Concurrency  with  Weapon  System 
Interagency  Shared  Software  Support 
Intelligence  Data  Usage 
Rapid  Reprogramming  Capability 
Higli  Frequency  Change 
Nuclear  Safety  Criteria 


f  ECS  Support  Deficiency  Corrections,  Support  System  Acquisition 


Table  2-4.  Summary  of  ECS  Support  Deficiencv  Corrections,  Generic  Change  Process  (Continued) 
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repository  exists  •  Establish  repository;  develop  automated  configuration  ALL 

software  baseline  management  and  documentation  tools,  with  network  com- 

i  mur.ication  to  repository 


Table  2-4.  Summary  of  ECS  Support  Deficiency  Corrections,  Generic  Change  Process  (Continued) 


able  2-5-  Summary  of  ECS  Support  Deficiency  Corrections,  Category  Unique  Support  Requirements 
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systems  intelligence  data  application  to  meeting  MAJCOM  readi- 


Table  2-5.  Summary  of  ECS  Support  Deficiency  Corrections,  Category  Unique  Support  Requirements 
(Continued) 


increase  the  F-I5’s  air-to-ground  capability,  and  the  F-4  which  is  equipped  with  an  ECS  that  has 
separate  software  for  the  reconnaissance  mission  on  the  RF-4C  and  the  air-to-ground  mission  on 
the  F-4E.  Although  an  ECS  which  is  assigned  multiple  roles  is  generally  supported  by  one  ALC 
organization,  interface  requirements,  testing  constraints,  and  configuration  management  sup¬ 
port  requirements  are  increased  significantly  by  the  use  of  an  ECS  for  multiple  roles. 

One  of  the  major  impacts  of  multiuse  ECS  is  on  the  System  and  Item  Managers.  The  assign¬ 
ment  of  an  ECS  to  an  SM  and/or  1M  has  serious  ramifications  from  several  aspects. 

•  If  a  multiple-use  ECS  is  assigned  to  an  Item  Manager:  How  does  the 
System  Manager  maintain  system  integrity?  What  is  the  impact  on  sup¬ 
port  tools  and  test  stands?  How  do  modifications  get  scheduled?  Who 
maintains  the  configuration?  How  is  distribution  of  the  modified  system 
affected? 

•  If  the  multiple-use  ECS  is  assigned  to  a  System  Manager:  How  does  the 
System  Manager  accept  requirements  from  a  second  System  Manager 
and  integrate  those  into  the  modification  schedule?  How  are  priorities 
established?  Who  funds,  schedules,  tests,  and  manages  the  configuration 
of  the  modifications? 

The  problems  that  the  ALC’s  will  face  because  of  multiple-use  ECS  are  numerous  and  v  ill 
become  even  more  complex  as  the  trend  increases  toward  developing  systems/subsystems  as  well 
as  munitions,  each  with  its  own  ECS,  for  use  on  several  different  weapon  systems.  In  addition, 
the  severity  of  the  problem  should  be  significantly  decreased  with  implementation  of  the  overall 
recommendations  presented  in  the  plan. 
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3.  ADMINISTRATIVE  INITIATIVES 


Volume  II  of  the  Phase  II  report  for  this  study  identified  several  key  ECS  support  issues 
faced  by  the  ECS  support  community.  These  issues  were  separated  into  administrative  and  pro¬ 
grammatic  activities  and  recommendations  were  provided  for  each  issue.  This  section  addresses 
those  issues  identified  in  the  Phase  11  report  and  other  recommended  initiatives  which  are 
primarily  administrative  in  nature,  particularly  in  the  early  stages  of  implementation.  Although 
the  initial  efforts  pertaining  to  the  resolution  of  these  issues  may  be  administrative  in  nature,  this 
does  not  preclude  the  establishment  of  later  programs  to  improve  discovered  deficiencies. 
Specific  recommendations  resulting  from  the  discussions  in  Volume  II  of  the  Phase  11  report  and 
this  section  are  combined  and  presented  in  Section  5  of  this  report.  The  following  additional  ini¬ 
tiatives  are  addressed  in  this  section. 

•  Management  and  Engineering  Practices 

•  Matrix  Organization 

•  ECS  Career  Progression 

•  Training  and  Professional  Education 

•  Acquisition  and  Support  Components 

•  Common  ECS  Support  Components 

•  Automatic  Test  Equipment 

•  Multi-ECS  Weapon  System  Support 

The  current  AFLC  management  and  engineering  structure  has  evolved  over  the  past  several 
years.  It  was  shaped  to  pt  jvide  support  to  systems  and  items  with  primary  emphasis  on  the  hard¬ 
ware  involved  and  was  further  designed  to  achieve  spare  and  repair  support  without  extensive 
regar^  to  engineering  development.  The  current  and  projected  ECS  support  role,  however,  is 
engineering  intensive  and  may  require  organizational  realignment  to  achieve  an  efficient,  effec¬ 
tive  ECS  support  posture.  The  organizational  structure  should  follow  the  system  approach  and 
include  each  function  of  management  and  engineering  for  ECS.  This  structure  would  require  a 
systems  management  approach  with  responsibilities  for  functional  areas  assigned  to  the  various 
team  members.  This  structure  would  address  all  aspects  of  ECS  support  within  the  command.  It 
would  provide  the  embedded  computer  resources  and  accomplish  the  management  and  technical 
support  for  ECS. 

Logistics  support  of  ECS  requires  a  systems  approach  due  to  the  many  interactions  within 
the  system’s  environment.  When  managers  plan,  they  must  take  into  account  the  external  vari- 
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able  such  as  user  requirements,  technology  impacts,  social  forces,  public  laws,  and  regulations. 
The  organizational  design  has  to  provide  an  environment  for  performance  of  the  logistics  func¬ 
tions  by  effective  use  of  internal  resources.  Management  must  design  planning  systems, 
organizational  systems,  control  systems,  and  resources  systems.  This  network  of  interrelated 
systems  requires  daily  interaction  between  the  systems  and  their  environments.  The  ECS  support 
function  must  be  included  in  the  logistics  support  functions  and  have  upper  management  sup¬ 
port  to  ensure  integration  of  ECS  requirements  into  the  overall  logistics  support  systems.  The 
task  of  management  is  to  transform  the  inputs  in  an  effective  and  efficient  manner  to  produce 
outputs.  A  typical  systems  management  model  is  shown  in  Figure  3-1. 

New  technologies  such  as  laser  systems,  worldwide  satellite  communications,  integrated 
systems,  and  multi-ECS  have  created  new  problems  as  well  as  new  capabilities.  As  a  result,  plans 
and  decisions  must  not  be  made  in  isolation.  The  impact  of  every  new  system  on  other  systems 
has  o  be  examined  with  meticulous  care.  This  requires  teams  of  technical  specialists  and  broadly 
experienced  generalists  who  can  make  effective  use  of  the  two  powerful  tools  that  enable  systems 
engineers  to  meet  the  challenges  provided  by  modern  technology. 

•  A  structured  methodology,  which  forces  even  the  most  specialized  indi¬ 
vidual  on  a  team  to  think  outside  his  speciality,  to  consider  its  interfaces 
with  other  disciplines,  and  to  ask  questions  until  at  least  the  requirements 
are  clear.  The  team  can  then  work  toward  solutions  that  best  meet 
systems  requirements. 

•  The  high  speed  digital  computer,  which  enormously  evoands  the  human 
ability  to  organize,  analyze,  and  evaluate  information  also  enable:, 
engineers  to  model  alternatives,  simulate  their  operation,  and  trade  off 
their  hypothetical  performance,  cost,  and  other  characteristics  before 
time,  money,  and  resources  are  invested  in  modifications  to  the  system. 

Even  with  these  tools,  the  key  ingredients  are  the  systems  engineers.  Only  they  can  apply  the 
judgement  that  is  needed  to  make  effective  use  of  the  full  spectrum  of  technology  to  produce  an 
optimal  design  which  meets  the  systems  requirements. 

AFLC  must  perform  systems  engineering  and  integration  of  large  complex  weapon  systems. 
The  techniques  and  practices  must  support  current  operating  systems  and  adapt  to  new  and 
improved  systems  based  on  high  technology  in  support  of  national  priorities.  For  this  reason, 
careful  planning  and  management  are  essential  throughout  the  life  of  the  system,  from  concep¬ 
tual  design  to  operational  use.  The  systems  engineering  process  will  provide  AFLC  the  means  to 
improve  design,  scheduling,  and  performance  of  the  weapon  and  support  system  and  reduce  life 
cycle  costs.  The  system  engineering  process  relies  on  the  system  engineer  and  it  is  likely  that  this 
will  drive  a  gradual  change  from  the  predominant  hardware  orientation  to  a  system  orientation. 
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Figure  3-1.  Systems  Management  Model 


HIIJWWip.  . . .  1,1 


{.‘••i  ii-: 


3.1  MANAGEMENT  AND  ENGINEERING  PRACTICES 

To  meet  the  challenges  suggested  by  the  issues  set  forth  n  the  Phase  11,  Vol\  me  11  report 
and  in  this  section,  AFl.C  management  and  engineering  practices  should  he  adjusted  u>  be  more 
attuned  with  the  highly  complex,  ti-'htly  integrated,  engineering  intensive  weapon  systems 
expected  to  accompany  the  Embedded  Computer  Systems  vECS’s)  Support  in  the  1930’s.  Major 
adjustments  in  this  regard  are 

•  Consolidate  software  and  hardware  engineering  personnel  in  a  single 
organization  at  each  ALC  to  facilitate  a  more  economical/responsive 
system  engineering  relationship  withi..  and  across  ALC’s, 

•  Establish  skill  centers  for  concentrated  specialities  across  the  ALC’s  to 
better  accommodate  emerging  technologies  and  to  heighten  the  advan¬ 
tages  afforded  through  a  matrix  structure, 

•  Develop  more  definitive  AFLC  career  incentives  and  progression  paths 
to  attract  and  retain  competent  ECS  personnel,  and 

•  Institute  a  more  structured  training  program  which  cycles  available  soft¬ 
ware  and  hardware  engineers  through  a  set  of  formal  courses  and  a  con¬ 
trolled  job  training  program. 

Corollary  to  these  adjustments  are  three  broad  based  initiatives  which  provide  a  framework 
for  implementation. 

•  The  HQ  AFLC  Logistics  Management  Office  (LOE),  in  providing 
overall  ECS  leadership  in  AFLC,  should  develop,  coordinate,  and  com¬ 
municate  to  the  ALC’s  ECS  support  strategies  as  well  as  the  framework 
of  policies  necessary  for  their  implementation. 

•  Hardware  and  software  engineering  resources  should  be  drawn  upon  in  a 
matrix  concept  where  plausible  by  the  managers  of  programs  and  pro¬ 
jects  within,  as  well  as  across,  ALC's. 

•  Continuing  efforts  should  be  made  at  HQ  AFLC,  ALD,  and  ALC  levels 
to  execute  the  AFLC  roles  and  missions,  as  assigned  by  current  ECS 
guidance,  with  as  much  emphasis  as  possible  placed  upon  mutual  coor¬ 
dination  and  communication. 

These  changes  and  initiatives,  together  with  the  more  specifically  focused  recommendations 
tendered  in  the  Phase  II  report,  will  stimulate  a  more  effective,  efficient,  and  responsive  means 
of  conducting  life  cycle  ECS  Operation  and  Support  (O&S).  The  text  which  follows  amplifies 
these  key  areas. 
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3.1.1  Matrix  Organization 

The  matrix  concept,  a',  v idy  an  integral  part  of  the  AFLC  structure,  is  the  fulcrum  upon 
which  rests  the  ECS  support  posture  of  the  1990’s.  Engineering  resources  will  simply  be  too 
scarce  to  programmatically  isolate  large  nests  of  such  expertise.  The  various  aspects  of  cross¬ 
utilizing  skills  and  capabilities  across  and  within  HQ  AFLC,  AFALD,  and  the  Air  Logistics 
Centers  are  discussed  herein. 

i  ■ 

3 . 1 . 1 . 1  Organizational  Structure/Functions 

■  Headquarters  Air  Force  Logistics  Command  (AFLC) 

The  primary  agencies  within  AFLC  which  have  an  impact  on  embedded  computer  support 
arc  DCS  Logistics  Operations  (LO),  DCS  Plans  and  Programs  (XR),  DCS  Maintenance  (MA), 
DCS  Manpower  and  Personnel  (DP),  and  Logistics  Management  (LM).  Logistics  Operations 
(LOE),  the  office  of  primary  responsibility  and  thus  responsible  for  policy,  guidance,  and 
resource  validation  affecting  ECS,  provides  support  to  the  operating  command  and  assures  ade¬ 
quate  resources  are  available  to  perform  this  task.  This  requires  inter-  and  intracommand  coor¬ 
dination,  policies,  guidance,  and  engineering/technical  support.  At  Headquarters  AFLC,  XR, 
MA,  LM,  and  DP  have  major  responsibilities  as  team  members  to  ensure  requirements  for 
resources  are  identified,  documented,  and  provided.  Table  3-1  highlights  the  breakout  of 
responsibilities  between  the  HQ  AFLC  organizations.  The  1990  ECS  support  strategy  and  the 
framework  of  policies  to  implement  this  strategy  must  be  developed,  coordinated,  and  com¬ 
municated  to  the  ALC’s  and  ALD  for  their  implementation.  In  addition  to  a  cooperative  effort 
by  all  ECS  team  members,  strong  leadership  by  LOE  will  be  required  to  develop  the  strategy  and 
policies,  and  to  master  technological  impacts  of  ECS  upon  the  command  resources. 

Air  Force  Acquistion  Logistics  Division  (AFALD) 

The  ALD  structure  provides  the  interface  and  interaction  with  AFSC  and  the  Defense 
Systems  Acquisition  Review  Council  (DSARC).  Early  pre-PMRT  action  is  one  of  the  most 
effective  ways  of  reducing  long-term  costs  of  logistics  support  of  ECS.  They  should  work  with 
AFSC  to  analyze  alternative  designs  early  in  the  development  cycle  of  those  systems  that  use 
embedded  computers.  Standardization  of  hardware  and  software  where  practical  will  help 
reduce  life  cycle  costs.  They  should  develop  life  cycle  cost  models  of  computer  hardware  and 
software  to  be  used  in  design  decisions  for  future  systems.  These  models  will  incorporate  all 
phases  of  logistic  support  for  each  ECS  category  including  required  data,  equipment,  and  per¬ 
sonnel.  They  should  become  skill  concentration;  as  identified  in  paragraph  3. 1.1. 2  for  standar- 

t  dization  and  identification  of  technology  impacts  through  AFSC  and  industry  interactions. 

i 
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They  should  work  with  the  Material  Management  Acquisition  Division  (MMA)  organization  to 
ensure  proper  plans  (i.e.,  CRISP,  PMP,  O/S  CMP,  etc.)  are  provided  at  PMRT.  The  Material 
Management  Engineering  Division  (MME)  through  MMA  should  provide  the  acquisition 
engineering  support  to  ALD.  A  coordinated  effort  between  ALD,  MMA  and  HQ  AFLC  is 
required  to  ensure  proper  embedded  computer  support  resources  are  provided  at  PMRT.  The 
identification  and  acquisition  of  these  resources  are  vital  to  performance  of  management  and 
technical  support  to  ECS. 

Air  Logistics  Centers  (ALC’s) 

The  ALC  structure  should  collect  the  ECS  hardware  and  software  engineers  into  the  service 
engineering  organization  with  this  organization  matrixed  to  provide  engineering  support  to  each 
ALC  user.  This  will  consolidate  engineering  personnel  and  will  allow  a  total  digital  engineering 
process  to  address  technical  problems,  reduce  training  requirements,  reduce  duplication  of 
critical  engineering  resources,  and  allow  a  career  ladder  w  ithin  the  area  of  professional  expertise. 
This  structure  will  provide  for  skill  concentration  to  address  new  technology  and  to  develop 
software  controlled  equipment  that  will  allow  reprogramming  to  be  done  at  a  lower  level  of 
technical  knowledge.  This  will  enable  engineers  to  work  complex  engineering  problems  and  will 
allow  technicians  to  perform  the  more  routine  reprogramming  and  documentation  functions. 
The  net  result  will  be  a  lower  number  of  digital  engineers  to  provide  engineering  and  technical 
ECS  support.  Figure  3-2  illustrates  this  partitioning  of  functions. 

The  systems,  item,  and  acquisition  divisions  require  engineering  management  expertise 
(system,  commodity  technology,  and  acquisition).  This  appears  best  satisfied  by  a  resident 
supervisory  level  engineer  permanently  detached  from  the  engineering  division.  Primary  func¬ 
tions  in  this  regard  are  to  provide  engineering  guidance  to  the  system  and  item  managers  and 
MMA,  coordinate  working  groups,  head  special  project  teams,  and  serve  as  technical  coor¬ 
dinator  for  the  technical  staff. 

The  engineering  division  is  a  logical  focal  point  for  all  engineering  within  the  ALC,  and 
would  be  assigned  all  practicing  engineers  (except  civil  and  industrial).  A  systems  engineering 
capability  would  be  established  at  each  ALC  to  provide  general  class  engineering  expertise  for  all 
Federal  Supply  Class  (FSC)  assigned  to  a  particular  ALC.  An  1SF  would  be  established  for 
standalone  systems.  An  acquisition  engineering  capability  would  be  established  at  each  ALC  to 
assist  MMA  and  the  Acquisition  Logistics  Division  in  establishing  engineering  support  require¬ 
ments  for  systems  in  acquisition.  Administrative  guidance,  office  space,  and  supplies  would  be 
provided  by  the  system  or  item  manager  (SM/1M)  for  co-located  engineering  personnel. 
Appraisals  would  be  performed  by  the  SM/1M  and  coordinated  by  the  engineering  division. 
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Manning  for  the  co-locatcd  functions  would  be  kept  at  the  minimal  levels  and  expertise  on  a  pro¬ 
ject  basis  would  be  matrixed  from  MME  as  required.  Any  SM/IM  could  draw  upon  the 
resources  of  another  ALC’s  MME  when  required,  with  the  stipulation  that  TOY  funding  must 
accompany  the  request.  Any  SM/IM  engineer  would  have  the  opportunity  to  use  another  ALC’s 
1SF  capability  or  participate  in  integration  testing  as  required. 

Existing  specialized  engineering  divisions  such  as  Material  Management  Communications 
Division  (MMC),  Material  Management  Aircrew  Trainers  Division  (MMF),  and  Material 
Management  Electronic  Warfare  Division  (MMR)  were  established  to  focus  management  and 
engineering  attention  in  a  specific  area.  These  and  other  areas  should  be  periodically  examined 
to  determine  the  need  for  their  strengthening  or  their  continuance  as  separate  entities. 

3. 1 . 1 .2  Skill  Concentrations 

Geographical  dispersement  of  the  ALC’s  and  the  lack  of  a  data  transfer  network  decreases 
communications  between  engineers  with  similar  weapon  system  support  problems  and  fosters 
duplication  of  effort  at  each  location.  With  the  total  number  of  ECS  engineering,  scientific,  and 
technical  personnel  needed  almost  certain  to  increase  in  the  next  decade,  the  centralization  of 
highly  skilled  engineers  and  scientists  is  approaching  compulsory.  Such  a  data  bank  for  solving 
complex  problems  will  serve  as  a  catalyst  for  professional  growth  and  development,  as  well  as 
increased  productivity.  Identificatiorl  of  these  skill  concentrations  and  implementation  of  a  net¬ 
work  syste*"  A'ill  provide  access  to  technology  trends  and  standards  for  multiple  AFLC 
organizations.  New  technology  can  be  analyzed  for  incorporation  into  the  ECS  support  posture 
with  the  requirements  for  new  development  tools/equipment  to  be  defined  for  the  AFSC  pto- 
gram  offices  and  laboratories.  These  skill  concentrations  would  provide  the  conduit  between 
AFLC  managers/engineers  and  other  commands/services  for  ECS  support  requirements  and 
technology  transfer.  Computer  program  exchange  and  on-the-job  training  by  experts,  as  well  as 
cost  savings  reaped  from  the  minimization  of  delays,  elimination  of  duplicate  developments, 
and  reduetio  :>f  tra  -e  additional  by-products  of  the  skill  concentration  concept. 

Skill  centers,  which  are  appropriately  interfaced  with  other  USAF  activities,  would  be 
beneficial  in  the  following  areas: 

•  High  order  '  lage; 

•  Repository  and  CM  Center  for  emulatators  and  other  software  tools; 

•  Repository  and  CM  Center  for  mathematical  models  of  aircraft, 
weapons,  environment,  sensors  and  actuators,  mission  models,  data- 
reduction  programs; 


•  Operator-computer  interactive  systems; 

•  Management  of  inter-center  communication  network;  and 

•  AFLC  initiated  standardization. 

Under  this  concept,  each  skill  concentration  would  be  responsible  to  research,  develop,  and 
disseminate  knowledge  throughout  AFLC.  The  development  and  dissemination  of  standards 
should  be  accomplished  by  ALD  as  this  organization  normally  has  first  knowledge  of  future 
system  technologies.  Once  identified,  F1Q  AFLC  would  assign  the  skill  area  to  an  ALC  for  the 
command’s  focal  point  of  expertise.  The  assigned  ALC  would,  in  turn,  provide  technical 
counsel  to  other  ALC’s  requiring  assistance.  These  skill  concentrations,  assisted  by  the  ECS  sup¬ 
port  network,  would  interface  with  program  offices,  laboratories,  and  industry  in  developing 
the  skill  capabilities. 

Skill  concentrations  should  likewise  be  developed  to  address  major  ECS  support  impacts  on 
AFLC,  such  as 

•  Networks, 

•  Standardization, 

•  Technology,  and 

•  Others,  as  identified. 

Formal  plans  for  the  develpment  of  these  skill  centers  and  supporting  facilities  for  the  sup¬ 
port  of  known  production  aircraft  and  probable  modifications  expected  during  the  next  ten 
years  should  be  prepared  by  HQ  AFLC,  with  schedules  and  budgets  prepared  by  the  ALC.  The 
commercial  practice  of  investing  two  to  five  percent  of  projected  system  costs  to  analyze  the 
economics  and  productivity  of  AFLC  internal  systems  and  facilities  in  advance  of  system  selec¬ 
tion  is  recommended  for  systems  entering  the  inventory  in  the  1985  to  2000  time  frame. 

3. 1 .2  ECS  Career  Progression 

The  ECS  engineering  discipline  requires  an  effective  career  management  program  to  attract 
and  retain  '•  alified  engineers  to  accomplish  the  necessary  ECS  support  in  a  highly  competitive 
environmei  .  Such  a  program  must  provide  for  classification  and  qualification  standard  adjust¬ 
ments,  professional  and  continuing  education,  training,  challenging  assignments,  a  means  to 
track  ECS  skills,  and  the  identification/communication  of  career  paths  that  are  made  available 
to  ECS  support  personnel. 
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Extending  beyond  the  problems  introduced  by  sheer  skill  shortages  are  problems  in  identi¬ 
fying  the  military  and  civilian  digital  engineers  available  for  ECS  support.  In  the  military,  there 
are  no  speciality  codes  which  reflect  the  expertise  needed  in  ECS.  While  expansions  have  been 
made  in  the  1550  technical  arena  (i.e.,  mathematics,  statistics,  computer  science)  the  civil  service 
qualification  and  classification  standards  do  not  recognize  software  engineering  as  a  discipline. 

Although  the  military  has  no  speciality  codes  to  reflect  the  expertise  needed  in  ECS  support, 
it  does  have  a  means  of  identifying  officers  with  special  experience  or  training  not  otherwise 
reflected  in  the  classification  system  by  AFSC’s.  These  special  experience  identifiers  (SEE)  com¬ 
plement  other  classification  tools  and  provide  the  means  to  retrieve  specific  experience  or  train¬ 
ing  for  use  in  satisfying  resource  management  requirements.  SEI’s  identify  experience  in  systems 
engineering  and  the  functional  areas  of  ATD,  ATE,  C-E,  EW,  and  OFP.  An  additional  com¬ 
plication  is  that  digital  engineers  do  not  want  to  be  identified  as  such  because  of  the  lack  of  up¬ 
ward  mobility.  Military  personnel  perceive  limited  promotion  possibilities  as  an  engineer  and 
civilian  personnel  who  acquire  a  computer  software  description  currently  tend  to  be  dead-ended 
at  the  GS-12  or  -13  level  unless  they  move  to  a  supervisory  position. 

It  is  thus  essential  that  any  AFLC  career  incentives  and  career  progression  paths  adopted  to 
attract  and  retain  competent  personnel  include  the  identification  of  promising  individuals,  the 
education  of  those  identified,  as  well  as  an  array  of  assignments  offering  opportunity  to  progress 
in  the  subject  career  field.  Such  career  control  would  improve  the  visibility  of  existing  expertise 
within  the  services  for  assignments  in  the  critical  area  of  ECS  support  and  other  important,  but 
less  essential,  jobs. 

An  example  of  a  career  progression  ladder  is  presented  in  Figure  3-3.  The  ladder  shows  the 
career  path  that  a  beginning  engineer  may  take  after  an  initial  assignment  to  MME.  The  training 
and  experience  will  qualify  the  engineer  to  become  a  team  member  for  acquisition  engineering 
for  a  new  system.  At  PMRT,  the  engineer  would  serve  as  a  primary  engineer  on  the  transitioned 
system.  At  the  seven-  to  eight-year  mark,  the  engineer  decides  upon  an  engineering  management 
or  a  technical  skill  path  and  obtains  the  appropriate  formal  education.  Upon  completion  of  the 
advanced  degree,  assignment  is  made  to  an  engineering  management  position  or  to  a  skill  con¬ 
centration.  Each  of  these  paths  lead  to  promotion  opportunities  at  the  GS-14  and  GS-15  levels. 
At  the  19-  or  20-year  point,  assignment  would  be  made  to  a  professional  military  school,  such  as 
the  National  War  College,  Air  War  College,  or  the  Industrial  College  of  the  Armed  Forces. 

The  key  point  is  establishment  of  engineering  management  and  technical  skill  career  paths 
that  lead  to  advanced  responsibilities  and  promotion.  The  engineer  chooses  a  path  and  manage- 
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ment  provides  opportunity  for  career  advancement.  Engineers  who  do  not  aspire  to  manage¬ 
ment  positions  or  high  technology  skills  should  be  assigned  to  challenging  positions  commen¬ 
surate  with  their  attained  grade.  They  would  be  assigned  to  career  broadening  areas  in  addition 
to  service  engineering  and  be  required  to  perform  at  an  acceptable  level  of  productivity.  A  career 
path  for  this  option  is  shown  in  Figure  3-4. 

AFLC  has  initiated  and  participated  in  engineer  management  programs  such  as  civil  service 
ssification  standards  which  is  in  the  approval/publishing  cycle  and  will  include  the  addition 
01  new  terms/disciplines  for  performing  ECS  support.  In  addition,  an  accelerated  promotion 
program  to  GS-12  in  2.5  years  has  been  implemented  and  the  AFLC  Director  of  Civilian  person¬ 
nel  (AFLC/DCP)  has  participated  in  conferences  to  develop  an  engineering  career  development 
program.  The  Air  Force  Logistics  Command  is  urged  to  continue  this  involvement,  while  seek¬ 
ing  to  develop/modify  civil  service  classification  and  qualification  standards  and  military 
specialty  codes  and  special  experience  identifiers. 

Other  initiatives  recommended  for  AFLC  adoption  are 

•  Develop  and  implement  a  career  management  program, 

•  Develop  and  implement  SEl’s  for  civil  servants, 

•  Develop  and  communicate  a  career  progression  ladder, 

•  Provide  engineering  management  and  technical  skills  career  paths, 

•  Make  assignments  within  the  career  path,  and 

•  Ensure  engineers  are  utilized  in  engineering  positions. 

3 . 1 .3  Training  and  Professional  Education 

One  method  recommended  for  obtaining  the  system  engineers  needed  to  meet  the  ECS 
challenge  of  the  1980’s  is  to  cycle  qualified  soft  ware  and  hardware  personnel  through  a  set  of 
formal  courses  and  a  structured  on-the-job  training  program.  The  training  required  to  qualify 
hardware  engineers  to  perform  ECS  system  engineering  tasks  includes  basic  computer  sciences 
and  software  engineering  courses,  system-related  courses,  and  on-the-job  training.  Com¬ 
monalities  among  the  digital  systems  supported  at  Air  Logistics  Centers  will  promote  the 
economic  development  of  the  basic  computer  science  skill  prerequisite  to  system-related  courses. 
Subjects  should  include 

m  Introduction  to  Digital  Computation; 

•  FORTRAN,  ATLAS,  JOVIAL,  or  Ada; 

•  Assembly  Language  Programming; 
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•  General  Purpose  Computers; 

•  Avionics  Computer/Software; 

•  Engineering  Data  Management  Systems; 

•  Simulation  and  Mathematical  Modeling;  and 

•  Data  Reduction  Analysis  Techniques. 

A  number  of  different  methods  are  available  to  obtain  the  necessary  system  engineering 
academic  training. 

•  AFIT  School  of  Logistics  Management 

•  AFIT  School  of  Engineering 

•  Air  Training  Command 

•  Public  universities  and  institutes 

•  Contractor-developed  courses 

•  In-house-developed  courses 

Because  no  one  method  can  satisfy  all  AFLC  training  requirements  when  time,  cost,  and 
course  content  are  considered,  a  combination  of  methods  are  required.  The  system-related 
courses  are  required  to  indoctrinate  personnel  with  the  mission  and  functions  performed  by 
target  systems.  System-related  courses  should  include:  system  overview  and  configuration, 
description  of  computer  programs,  instruction  on  specific  assembly  language  test  methods,  and 
hardware  capabilities  and  limitations. 

Experience  indicates  that  the  most  comprehensive  training  is  achieved  by  over-the-shoulder 
observation  and  dedicated  work  with  contractor  personnel  at  the  contractor  facility  during 
system  development.  This  training  should  follow  the  formal  course  work  and  should  be  the  step¬ 
ping  stone  for  assuming  responsibilities  for  organic  support.  This  training  should  be  consistent 
with  the  typical  career  path  discussed  in  the  previous  sections.  Most  of  this  over-the-shoulder 
training  should  come  during  the  systems  acquisitions  cycle  so  the  system  engineer  is  fully  capable 
of  supporting  the  new  systems  at  PMRT.  To  offset  the  time  lost  for  training,  communication 
resource  centers  should  be  established  at  each  ALC.  These  centers,  primarily  established  for 
teleconferencing,  should  have  the  following: 

•  Conference  area  with  large  display  screen, 

•  Conference  room  with  individual  display  and  imaging  consoles, 
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•  Video  transmission  system  with  studio  and  control  room  tor  orginating 
training  programs  and  conference  briefings, 

•  Classrooms  for  live  presentations  and  demonstrations, 

•  Outlets  for  local  network  interconnects, 

•  Room  for  multiple  student  training  consoles,  and 

•  Student  console  features  (Video  screen  and  control,  private  audio  output 
audio  input  such  as  microphone,  text  keyboard,  and  switchable  input, 
network,  or  video  disk  teaching  machine). 

System  engineering  and  technician  training  requirements  should  be  consolidated  and  a  plan 
developed  which  describes  the  needs,  applicable  methods  and  resources  required.  To  satisfy  the 
long  time  planning  goals  of  this  document,  the  f  Mowing  actions  are  recommended. 

•  Expand  the  AF1T  School  of  Logistics  Management  courses,  to  include  a 
specific  section  on  ECS  systems  management. 

•  Develop  short  course  on  ECS  systems  management  for  the  teleteach 
systems  and  follow  on  communications  media,  to  include  video  network 
and  video  disks. 

•  Develop  a  series  of  basic  computer  science  courses  for  wide  area  use  on 
video  networks  or  local  use  of  video  teaching  systems. 

•  Develop  a  basic  systems  engineering  course  for  wide  area  use  on  video 
networks  or  local  use  on  video  disk  teaching  systems. 

•  Encourage  AFIT  Electrical  Engineering  (EE)  and  Computer  Science  (CS) 
students,  projected  for  AFLC  assignments,  to  specialize  in  subjects 
relating  to  ECS  support. 

•  Establish  a  method  to  actively  recruit  AFIT  electrical  eng.neering  and 
computer  science  students. 

•  Incorporate  video  instruction  requirements  into  communications  net¬ 
work  studies  and  analysis. 

•  Use  off-shelf  video  instruction  and  telecomunication  services  offered  by 
commercial  companies  or  public  utilities  where  economically  feasible. 

•  Develop  a  comprehensive  instruction  and  training  plan  for  ECS  support 
personnel  which  complements  the  career  ladder. 

•  Develop  communication  resource  centers  at  each  ALC. 
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3.2  ACQUISITION  AND  SUPPORT  PRACTICES 


AFLC  engineering  requirements  for  supporting  systems  are  related  to  the  quality  of  weapon 
systems  at  transition  (transfer  of  support  responsibility  from  a  development  phase  to  an  opera¬ 
tional/support  phase).  It  is  generally  accepted  that  those  systems  which  meet  performance  and 
reliability  specifications  require  less  engineering  support  than  those  systems  with  latent  deficien¬ 
cies  or  those  which  possess  performance  shortfalls.  At  the  same  time,  it  is  a  well-established 
premise  that  early  detection  of  system  deficiencies  or  necessary  improvements  involving  ECS  is 
more  cost  effective  if  corrective  actions  are  initiated  early  in  the  system  development  phase  as 
opposed  to  a  later  correction.  Recognizing  this  fact,  certain  procedures  and/or  emphases  can  be 
implemented  with  a  good  potential  for  improving  product  quality  at  transition.  These  emphases 
are  not  applied  without  a  development  cost  perturbation,  yet  the  overall  result  is  a  reduced  life 
cycle  cost.  The  purpose  of  this  section  is  to  address  improvements  with  the  expectation  that  their 
implementation  will  improve  system  qual'tv  at  transition  and  reduce  overall  life  cycle  costs.  The 
improvements  are  divided  into  two  groups:  weapon  systems  and  support  systems. 

Weapon  System  Improvements 

Volume  II  and  Volume  IV  of  the  Phase  11  report  adcress  cases  where  poor  quality  systems 
have  transitioned.  There  are  numerous  factors  which  can  cause  poor  quality,  many  of  which  are 
addressed  within  previously  written  volumes.  The  discussion  here  is  presented  to  emphasize 
some  improvement  areas  to  help  ensure  improved  quality.  Although  improvements  such  as 
IV&V  and  design  for  testability  were  previously  addressed,  they  are  important  enough  to  war¬ 
rant  coverage  here  also.  The  specific  improvement  areas  addressed  are:  conduct  IV&V  during 
development,  limit  system  proliferation  through  additional  commonality  and  planning  em¬ 
phases,  emphasize  design  for  testability,  and  stress  better  documentation  for  the  systems. 

Conduct  Independent  Verification  and  Validation 

The  attributes  and  components  of  IV&V  were  discussed  in  Section  9. 2. 2. 3,  Volume  II  of  the 
Phase  11  report.  Summarily,  IV&V  implements  more  testing,  configuration,  and  product 
analysis  whose  overall  purpose  is  to  improve  quality  by  ensuring  that  requirements  and  perfor¬ 
mance  specifications  are  satisfied. 

In  ensuring  that  quality  and  supportable  software  is  delivered  to  AFLC,  the  most  important 
single  activity  is  IV&V  conducted  by  or  under  the  cognizance  of  the  eventual  support  agency.  In 
referencing  the  definciencies  related  to  product  quality  highlighted  in  the  Phase  II  report, 
Volume  II  of  this  study,  the  alternative  with  the  most  apparent  payoff  is  a  full  in-phase  IV&V. 
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These  deficiencies  can  be  categorized  into  the  following: 

1.  Latent  software  discrepancies, 

2.  Documentation  deficiencies,  and 

3.  Support  tool  deficienceis. 

It  can  be  easily  seen  that  a  wcll-structure  IV&V  by  the  support  agency  can  remedy,  or  as  a 
minimum,  greatly  improve  all  of  these  categories.  The  IV&V  approach  provides  the  support 
agency  with  the  opportunity  to 

1 .  Discover  latent  deficiencies  during  the  development  process  and  propose 
them  for  correction, 

2.  Uncover  documentation  inconsistencies  and  insist  on  correction,  and 

3.  Independently  assess  and  develop  additional  support  tools. 

In  doing  this,  the  support  agency  can  satisfy  itself  that 

1.  The  software  requirements  adequately  reflect  the  system  requirements, 

2.  The  software  design  satisfies  these  requirements, 

3.  The  operational  code  (computer  instructions  and  data)  correctly  im¬ 
plements  the  design, 

4.  No  unauthorized  code  is  present, 

5.  The  operational  code  meets  accuracy  and  performance  requirements  for 
the  system  in  its  intended  operational  environment, 

6.  The  documentation  adequately  describes  and  accurately  represents  the 
baseline  computer  programs,  and 

7.  That  test  and  support  tools  are  adequate  for  extended  support. 

Recognizing  that  accomplishment  of  the  above  activities  requires  a  wide  range  of  expertise  and 
related  experience,  encompassing  hardware,  software  and  system  disciplines,  it  probably  will  not 
be  possible  for  all  eventual  support  activities  to  possess  the  in-house  ability  for  IV&V.  Alter¬ 
natives  whereby  the  activity  is  done  under  the  close  cognizance  of  the  support  agency  should  be 
examined. 

In  most  previous  developments  very  little  IV&V  has  been  implemented  during  the  system 
development  phase  except  for  space  and  missile  systems.  Rather,  IV&V  for  most  other  systems 
was  implemented  after  discovery  of  defectiveness  to  ascertain  the  overall  significance  of  the 
defectiveness.  IV&V  has  its  maximum  yield  when  implemented  in  parallel  with  the  development 
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because  this  exercises  and  tests  the  developing  system  in  a  manner  to  indicate  deficiencies  and  at 
a  time  when  a  correction  is  less  impacting.  In  spite  of  the  early  implementation  of  IV&V  being 
more  cost  effective,  it  is  seldom  implemented  except  for  high  risk  programs  or  those  involving 
nuclear  weapons  because  it  adds  an  additional  cost  burden  to  the  development.  1V&V  offsets 
intangible  costs  and  a  Program  Manager  interested  in  reducing  development  cost  is  not 
necessarily  motivated  to  spending  for  deficiency  prevention  or  for  supportability  issues. 

While  some  level  of  v&v  may  be  employed  by  the  acquisition  agency  and  should  be 
encouraged  by  AFLC,  the  high  leverage  of  IV&V  to  AFLC  is  application  of  the  technique  by 
AFLC  prioi  to  PMRT.  The  primary  concern  of  AFLC  during  the  system  acquisition  phase  is 
system  supportability  and  the  acquisition  of  ECS  support  facilities,  tools,  equipment,  personnel, 
and  training.  Therefore,  AFLC  commitment  to  perform  some  level  of  I  V&V  (depending  upon 
ECS  complexity)  accomplishes  two  goals.  First,  it  puts  the  development  command  on  notice  that 
ECS  supportability  is  a  firm  requirement  and  second,  by  acquiring  ECS  suppou  facilities  (tools, 
equipment,  and  personnel)  to  perform  the  IV&V  it  places  AFLC  in  a  position  to  enforce  sup¬ 
portability  concerns  prior  to  PMRT  as  well  as  assumption  of  the  posture  to  support  the  system 
at  PMRT. 

Limit  Support  System  Proliferation  by  Stressing  Commonality 

System  developments  through  the  past  several  years  have  tended  toward  independent, 
unique  systems  with  little  attention  to  other  similar  developments  and  with  little  attention 
toward  modularity.  As  a  result,  not  only  is  each  developed  system  an  entity  of  its  own,  but  its 
support  system  is  unique  (or  near'y  so).  Without  any  modularity  and/or  commonality  con¬ 
siderations,  each  system  “reinvents  the  wheel”  by  developing  all  of  its  components  from  scratch 
with  little  or  no  attempt  to  capitalize  on  previous  component  developments.  If  a  development 
approach  using  modules  was  used,  the  building  blocks  or  components  would  become  technically 
stable  thus  combining  into  more  reliable,  quality  systems. 

The  composite  of  multiple  separate  systems  compounds  the  demands  for  engineering  sup¬ 
port.  Reducing  the  number  of  dissimilar  dedicated  ECS  support  systems  would  lessen  the  AFLC 
support  requ'rements  for  ECS.  At  the  same  time,  using  stabilized  and  proven  modules  or  com¬ 
ponents  t.s  basic  building  blocks  for  systems  and  ECS  support  systems  will  tend  toward  higher 
qualify  &\  stents  thus  lessening  support  impacts  upon  AFLC.  Efforts  such  as  the  VHSIC  project 
promise  to  help  because  of  the  emphasis  of  functional  modules.  Chips  or  components  are 
designed  for  purposes  which  apply  to  more  than  one  application,  yet  they  are  oound  by  con¬ 
trolled  or  standard  interfaces.  If  more  emphasis  and  approaches  similar  to  VHSIC  were  applied 
to  system  development,  then  common  portions  of  systems  would  improve  overall  system  quality 
this  reducing  overall  support  requirements. 


3-19 


Implement  Design  for  Testability 


Quite  often  weapon  systems  are  designed  with  operational  and  reliability  considerations  in 
mind,  but  with  insufficent  attention  focused  on  how  to  test  the  system.  ECS  systems,  in  par¬ 
ticular,  are  sensitive  to  unexpected  disruptions  such  as  unprogrammed  external  stimuli  for 
testing.  Certain  systems  lack  I/O  pins  for  testing  and  are  virtually  impossible  to  test  without 
disturbing  their  natural  state,  thus  any  administered  tests  are  in  an  unrealistic  environment. 
Adding  a  “test”  capability  to  an  established  design  often  has  derogatory  effects  upon  the 
system,  whereas,  if  the  system  had  been  designed  with  testability  in  mind,  the  probability  of 
system  degradation  to  facilitate  a  testing  capability  is  lessened.  It  follows,  without  direct  proof, 
that  systems  which  are  designed  to  be  tested  will  be  tested  more  thoroughly  than  those  not 
designed  for  testing. 

The  probability  of  testing  of  chips,  components,  etc.  getting  more  complex  and 
sophisticated  is  proportional  to  the  amount  of  design  consideration  for  that  purpose.  An  AFLC 
long-range  support  objective  is  to  minimize  complexity.  This  minimization  can  be  assisted  by 
additional  emphasis  to  such  functions  as  built-in-test  and  fault-isolation-testing  (BIT/FIT).  The 
VHS1C  project  is  a  good  example  of  this.  Not  only  is  VHSIC  focusing  upon  functional  modules, 
but  modules  which  are  self-testable. 


Stress  Adequate  Documentation 

Inadequate  documentation  has  been  a  common  accompaniment  for  many  previous  ECS 
system  developments.  This  issue  has  been  addressed  from  a  different  perspective  in  several 
earlier  study  volumes  but  documentation  is  directly  relevant  to  product  quality  because  it 
describes  the  product  and  how  to  use  and  test  it.  Documentaion  is  expensive  to  generate  and 
often  the  developing  contractor  or  agency  possesses  enough  internal  engineering  data  to  con¬ 
tinue  development  but  the  data  is  not  deliverable  or  is  in  an  externally  undecipherable  format. 


Poor  documentation  practices  and  improper  planning  appear  to  be  the  most  common  faults 
resulting  in  incomplete  or  inadequate  documentation.  The  problem  is  one  of  management 
emphasis.  The  solution  to  this  problem  is  not  only  better  planning  and  implementation  by 
management  levels  but  clearly  stated  requirements  for  acquisition  of  baseline  documentation 
combined  with  automated,  standardized  processes  and  procedures  for  maintaining  the 
baselines. 

Support  Sy stems  Improvements 

As  weapon  systems  have  evolved  to  higher  and  higher  sophistications  and  complexities,  the 
associated  support  systems  have  also  become  more  complex.  Support  systems  have  migrated 
from  simple  analyzers  to  AlSF’s.  This  migration  has  been  attended  by  large  changes  in  relative 
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costs  for  support  systems.  What  was  an  inconsequential  cost  for  a  support  system  only  ten  years 
ago  has  now  turned  into  a  cost  large  enough  to  impact  the  basic  system  development.  The  evolu¬ 
tion  of  support  system  complexity  is  still  in  process  and,  because  of  this  dynamic  state,  several 
support  systems  are  of  lesser  quality  than  desired.  The  purpose  of  discussing  this  issue  is  to 
highlight  some  suggested  areas  for  improving  quality  for  subsequent  support  systems. 

Assuming  that  overall  quality  of  weapon  systems  could  be  vastly  improved,  there  will  still 
be  a  requirement  for  support  systems  such  as  AISF’s  because  of  the  nature  of  ECS  components 
and  the  need  for  a  realistic  environment  for  conduct  of  the  ECS  change  process.  Curing  weapon 
system  quality  problems  will  not  necessarily  cure  support  system  quality;  however,  it  has  high 
potential  to  reduce  the  overall  loading  for  support  systems.  Fewer  unique  systems,  adequate 
documentation,  higher  quality  software,  and  better  testability  will  tend  to  reduce  the  overall 
support  required  from  AFLC. 

Plan  and  Acquire  Modular  Support  Systems 

This  emphasis  is  somewhat  overlapping  with  the  modular  1SF  addressed  in  Section  4,2.  The 
use  of  a  series  of  building  blocks  which  are  common  between  all  support  systems  will  quickly 
evolve  to  stabilize  verified  components  whose  quality,  performance,  and  reliability  will  be 
known  and  thus  can  be  factored  into  support  system  acquisition.  The  Computer  Resources 
Working  Group  (CRWG)  and  the  Computer  Resources  Integrated  Support  Plan  (CRISP)  pro¬ 
vide  the  vehicle  and  the  means  for  identifying  support  resources. 

Ensure  Weapon  System  Changes  Compatible  with  Support  Systems 

This  is  a  multi-faceted  emphasis.  First,  there  is  a  genuine  need  for  validated  simulators  in 
support  systems  and  trainers  to  ensure  that  their  functions  are  accurate  and  realistic.  Second, 
trainers  need  to  be  more  architecturally  aligned  with  the  weapon  system  than  they  currently  are. 
Third,  weapon  system  changes  must  be  compatible  with  test  systems  versions.  Each  of  these 
facets  is  addressed  in  the  following  paragraphs. 

•  Simulator  Validation.  The  simulators  addressed  here  are  ground  EW 
simulators  which  simulate  enemy  capabilities.  In  the  absence  of  having 
the  real  systems,  simulation  is  necessary;  however,  if  air  missions  are  to 
train  as  a  result  of  these  simulators  then  the  simulations  must  be 
accurate.  Future  simulations  of  this  type  must  be  validated  through 
testing,  analysis,  and  exercise  to  portray  a  realistic  training  scenario  for 
mission  aircraft.  1V&V  promises  a  good  approach  to  this  validation  ef¬ 
fort. 

•  Trainers  Aligned  with  Weapon  Systems.  Many  ATD’s  are 
independently  developed  from  the  weapon  systems  themselves,  thus  the 
ATD’s  and  weapon  system  do  not  utilize  any  appreciable  amount  of 
equipment  or  software  commonality.  This  results  in  subsquent  weapon 
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system  changes  not  translating  directly  to  changes  in  the  ATD.  As  addi¬ 
tional  changes  compound,  the  ATD  deviates  increasingly  such  that 
realistic  training,  in  some  cases,  is  not  achievable.  There  needs  to  be  addi¬ 
tional  emphasis  on  upfront  planning  for  ATD  to  ensure  that  more  long 
term  utility  of  the  trainers  is  possible. 

•  Weapon  System  Changes  Compatible  with  Test  System  Version. 

Sometimes  weapon  systems  undergo  changes  without  any  changes  to  test 
equipment  being  processed.  This  often  happens  prior  to  transition  so 
there  is  a  distinct  probability  that  test  systems  will  not  adequately  test  the 
unit  for  which  they  were  designed.  There  needs  to  be  additional  stress  to 
ensure  that  test  system  versions  equate  to  the  unit  to  be  tested. 

3.2.1  Common  ECS  Support  Components 

AFLC  should  quantitatively  investigate  the  economic  advantages  of  standardized  simula¬ 
tion  software  for  use  in  weapon  system  integration  support  facilities  and  also  in  aircrew  training 
simulators.  The  current  approach  of  separate  development  of  this  simulation  software  for  each 
individual  application  can  cause  a  large  duplication  of  effort.  There  is  further  duplication  of 
effort  in  maintaining  separate  simulations  of  these  same  functions.  However,  because  multi-use 
simulations  are  often  more  complex  and  costly  than  those  customized  to  a  particular  usage, 
economic  analysis  and  planning  is  required  on  a  case-by-case  basis. 

3 .2. 1.1  ATD  Maintenance  on  A1SF 

Maintenance  of  aircrew  training  simulator  software  in  the  A1SF  has  been  discussed  (ECS 
Study  Baseline  Report,  Volume  III)  as  a  partial  solution  to  the  problem  of  maintaining  the  ATD 
concurrent  with  the  weapon  system.  A  major  problem  with  maintaining  this  software  on  the 
A1SF  is  that,  although  the  ATD  an  l  A1SF  may  simulate  exactly  the  same  weapon  system  func¬ 
tions,  they  usually  do  so  with  different  software  models  which  have  different  levels  of  fidelity. 
Therefore,  updating  A1SF  software  to  a  new  configuration  does  not  automatically  produce  a 
product  usable  in  the  ATD.  However,  the  A1SF  software  update  could  make  corresponding 
ATD  software  updates  much  easier  if  both  were  performed  by  the  same  personnel.  Whenever  it 
is  practical  to  use  identical  simulations  in  the  ATD  and  A1SF,  by  using  software  which  meets  or 
exceeds  the  requirements  of  both  applications,  the  duplication  of  maintenance  effort  could  be 
avoided  and  concurrency  improved.  An  example  of  possible  commonality  between  ATD  and 
AISF’s  is  given  in  the  following  paragraphs. 

3.2. 1.2  ATD/A1SF  Common  Support  Example 

When  an  AISF  is  used  to  support  the  modification  of  digital  avionics,  it  is  frequently 
necessary  to  modify  the  AISF  to  incorporate  pertinent  weapon  system  changes  prior  to  develop¬ 
ment  of  new  avionics  OFP’s.  When  the  AISF  modifications  are  complete  and  the  new  OFP’s 
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developed,  the  updated  hardware  and  software  could  be  used  to  update  any  modules  common  in 
function  and  design  with  an  Aircrew  Training  Device  (ATD).  In  this  section,  the  degree  of  com¬ 
monality  which  is  conceptually  feasible  between  an  AISF  and  a  weapon  system  trainer  (WST)  is 
examined.  The  example  is  generic,  but  is  based  on  the  F-16  weapon  system. 

Figure  3-5  shows  a  conceptual  view'  of  an  AISF.  The  heart  of  the  AISF  is  the  aircraft 
avionics  systems,  which  are  in  this  example  interfaced  via  a  M1L-STD  1553  serial  multiplex  data 
bus.  Certain  of  the  avionics  functions,  such  as  the  inertial  navigation  system  and  the  radar  hard¬ 
ware,  are  simulated  in  this  example.  The  AISF  simulation  host  computers  real  time  functions 
could  be  divided  into  simulation  executive,  aircraft  and  environment  stimulation,  simulation  of 
certain  avionics,  AISF  operator  interface  (pilot  displays  and  controls  plus  visual  system),  and 
data  collection  (CMAC  data,  bus  data  and  simulation  data).  Non-real  time  functions  include 
test  scenario  generation  and  post-test  data  analysis. 

Figure  3-6  shows  an  example  of  the  comparable  weapon  system  trainers.  In  this  example,  a 
partial  compliment  of  onboard  avionics  is  included  in  the  WST.  The  inertial  navigation  system 
(INS)  and  fire  control  radar  (FCR)  hardware  are  simulated,  so  the  overall  avionics  configuration 
is  the  same  as  in  the  AISF,  The  remaining  simulator  software  contains  functions  very  similar  to 
those  of  the  AISF.  These  include  the  aircraft  and  environmental  simulation,  real  time  executive, 
real  time  data  collection,  scenario  generation,  and  post-test  performance  scoring.  The  weapon 
system  trainer  has  no  computer  monitor  and  control  requirement,  but  has  both  student  and 
instructor  consoles. 

A  comparison  of  common  functional  modules  is  presented  in  Table  3-2.  The  avionics  com¬ 
pliment  including  OFP’s  and  simulation  of  certain  avionics  hardware  (radar,  INS,  CADC) 
could  conceptually  be  identical  in  both  the  AISF  and  WST,  although  the  simulations  in  both 
would  have  to  meet  the  higher  of  the  two  requirements.  The  visual  display  used  to  provide  a 
windshield  view  for  the  HUD  might  be  considerably  simpler  in  the  AISF  than  would  be  needed 
in  the  ATD.  However,  the  AISF  displays  and  operator’s  console  might  be  usable  for  the  instruc¬ 
tors’s  console.  The  AISF  would  not  have  a  counterpart  of  the  ATD  pilot’s  console. 

The  aircraft  and  environmental  simulations  could  probably  be  identical  for  AISF  and 
simulator.  Simulation  data  collection  software,  test  control  software,  and  post -test  data  reduc¬ 
tion  software  would  have  lesser  similarity.  The  ATD  would  not  require  CMAC’s  or  M1L-STD 
1553  bus  monitors. 

In  summary,  a  major  portion  of  the  hardware  and  software  used  in  real  time  operation  of 
the  example  AISF  could  be  identical  to  that  used  in  the  corresponding  WST.  This  high  degree  of 
commonality  would  allow  the  AISF  to  be  of  significant  benefit  in  WST  operation  and  support. 
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Example  of  Weapon  System  Trainer/Aircrew 
Training  Device 


Table  3-2.  Components  Common  to  AISF  and  ATD/WST  Functions 


Table  3-2.  Components  Common  to  AISF  and  ATD/WST  Functions  (Concluded) 


3.2. 1.3  Standard  Simulation  Candidates 


The  following  candidates  are  a  partial  list  of  simulated  functions  which  potentially  have 
multiple  application. 

•  Aircraft  dynamics  simulation 

•  Earth  model 

•  Earth  gravity  model 

•  Earth  atmosphere  model 

•  Terrain  model 

•  Sensor  models  (radar,  IR,  laser  designator,  etc.) 

•  Inertial  platform  models 

Standard  simulations  could  be  developed  as  software  packages  intended  to  be  rehosted  on 
the  various  ATD  and  A1SF  simulation  computers,  or  developed  and  hosted  on  a  low  cost, 
readily  available  minicomputer  or  microcor.iputer.  Standard  simulation  users  would  then  have 
to  procure  and  interface  the  standard  host  to  their  system  rather  than  rehosting  the  software 
simulation. 

3. 2. 1.4  Obstacles  to  Common  Components 

There  are  numerous  managerial  and  technical  reasons  for  the  current  approach  of  repeated 
development  of  simulations  of  the  same  functions.  These  reasons  include  the  following: 

•  Funding  and  responsibility  for  development  of  weapon  system  simula¬ 
tions  are  assigned  on  a  project-by-project  basis; 

•  Standard  simulations  must  be  developed  in  response  to  the  requirements 
of  a  variety  of  users,  instead  of  those  of  a  single  project,  and  are  pro¬ 
bably  more  expensive  to  develop  than  a  single  simulation  which  meets  the 
requirements  of  only  a  single  project; 

•  Standard  simulations  probably  will  require  more  host  computer  memory 
and  CPU  time  than  a  custom  simulation; 

•  Lack  of  standardization  of  computer  higher  order  languages  and  instruc¬ 
tion  set  architectures  has  been  an  obstacle  to  software  transportability; 
and 

•  The  high  cost  of  digital  hardware  and  lack  of  standard  high  speed  inter¬ 
face  protocols  have,  in  the  past,  been  a  barrier  to  the  development  of 
standard  hardware/software  simulation  packages. 
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Funding  and  development  responsibility  is  a  management  constraint,  and  could  be  resolved 
by  management  action.  The  cost  effectivity  of  standardization  needs  to  be  resolved  by  quan¬ 
titative  analysis  on  a  case-by-case  basis.  The  last  three  obstacles  are  becoming  less  important  due 
to  standardization  of  programming  languages,  lower  cost  hardware,  and  increasing  standardiza¬ 
tion  of  interface  protocols. 

3. 2. 1.5  Management  Approach 

In  concept,  responsibility  for  development  of  a  standard  subsystem  simulation  (sensor, 
inertial  platform,  etc.)  could  be  assigned  to  the  agency  responsible  for  development  or  support 
of  the  subsystem.  A  skill  center  could  be  assigned  as  Office  of  Primary  Responsibility  for  main¬ 
taining  environmental  mode's  (gravity  models,  atmosphere  models,  earth  and  terrain  models, 
etc.).  The  same  skill  center  could  be  assigned  responsibility  for  maintaining  standard  aircraft 
simulations.  These  should  be  assigned  to  a  skill  center  rather  than  the  aircraft  program  office 
(PO)  since  the  same  simulation  equations  could  be  used  to  represent  different  aircraft,  with  only 
data  changes  (aerodynamic  and  mass  property  data  coefficients,  etc.)  to  model  different  air¬ 
craft.  The  responsibility  for  generation  of  the  specific  data  coefficients  ;or  a  particular  model 
aircraft  could  be  obtained  from  the  particular  aircraft  PO. 

AFLC  actions  required  to  develop  standard  simulations  are 

•  Perform  cost  analysis  to -select  most  cost  effective  function(s)  for  stan¬ 
dard  simulations, 

•  Resolve  funding  constraint  by  management  action, 

•  Establish  Office  of  Primary  Responsibility  for  standard  simulations, 

•  Perform  user  requirements  analysis  for  each  candidate  standard  simula¬ 
tion, 

•  Determine  simulation  hosting  approach, 

•  Perform  availability  survey, 

•  Obtain  and  test  prototype, 

•  Install  prototype  system  and  determine  prototype  deficiencies, 

•  Correct  deficiencies  and  produce  operational  versions  of  standard 
simulation,  and 

•  Maintain  repository  for  standard  simulations. 

Certain  of  the  above  actions  should  of  course  be  coordinated  with  other  agencies,  such  as 
ASD  and  the  Simulator  Program  Office  (S1MSPO),  to  ensure  that  the  standard  simulations 
meet  the  requirements  of  all  potential  users. 
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3.2.2  Automatic  Test  Equipment 

Testing  has  evolved  from  the  age  of  reliability  through  the  age  of  flexibility  into  the  age  of 
complexity.  The  evolution  is  continuing,  but  the  question  is:  where  is  ATE  heading?  ATE  u^ers 
still  demand  reliability  of  testing,  they  still  need  flexibility,  and  they  are  confronted  with 
runaway  complexity.  Against  this  familiar  background,  several  developing  trends  are  noted. 

The  cost  of  programming  and  supporting  ATE  is  increasing  faster  than  the  cost  of  the 
equipment  itself.  But  as  the  cost  of  computing  power  drops,  it  will  be  easier  to  equip  systems 
with  more  built-in  aids  and  to  apply  the  massive  computing  power  to  device  modeling. 

There  is  a  growing  tendency  for  built-in  test,  ATE,  and  A1SF  to  overlap  each  other.  The 
distinction  of  one  from  the  other  is  no  longer  as  clear  as  in  the  past. 

ATE  technology  is  finding  broader  application  in  engineering  and  field  service.  In  other 
words,  consideration  for  ATE  is  impacting  engineering  design  and  the  power  of  ATE  is  being 
used  by  service  technicians. 

Testing  represents  an  increasing  share  of  the  total  manufacturing  dollar.  IV&V  can  be 
thought  of  as  a  form  of  testing  so,  although  hardware  costs  are  down  and  are  attended  by 
lowered  hardware  testing  costs,  expanded  use  of  IV&V  will  likely  occur  until  software 
modularity  is  more  prominent. 

Test  equipment  will  increasingly  incorporate  seif-test  and  auto  calibration  as  the  associated 
costs  of  these  functions  go  down.  Simplified  interfaces  will  also  prevail. 

Instruments  will  be  broken  up  into  several  applications  categories.  A  constant  base  of  re¬ 
quirements  will  continue  to  call  for  flexible,  manually  operated  instrumentation  for  an  array  of 
capabilities  which  do  not  use  repetitive  measurements.  At  the  same  time,  microprocessor 
technology  will  provide  improved  performance  over  currently  used  general  purpose  equipment. 

Finally,  general  purpose  instruments  oriented  toward  users  who  want  to  put  ATE  systems 
together  will  incorporate  bus  adaptability  and  these  instruments  will  use  higher  operating 
speeds. 
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A  recent  review  across  the  spectrum  of  ATE  manufacturers  and  users  cited  the  forecasted 
major  challenges  for  the  coming  decade  are 

•  Testing  and  performing  fault  isolation  on  microprocessor-populated  pro¬ 
ducts; 


•  Problems  and  challenges  created  by  the  growing  popularity  of  fiber- 
optics; 

•  Need  for  some  form  of  BIT  for  LSI  and  VLSI  components; 

•  Problems  involved  in  testing  new,  large  memory  devices; 

•  Urgent  need  to  develop  functional  programs  and  fault  isolation  cap¬ 
ability  for  complex  UUT’s  at  a  reasonable  cost; 

•  Requirements  for  analog  ATE  and  fault  isolation  capabilities;  and 

•  Need  for  digital  in-circuit  capability  for  handling  LSI  devices. 

In  view  of  these  trends  and  challenges,  ATE  is  destined  for  increased  emphasis  throughout 
the  next  decade.  AFLC  will  be  affected  bv  the  dynamics  of  ATE  and,  unless  adequate  upfront 
planning  is  implemented,  the  command  will  be  controlled  by  the  dynamics  rather  than  controll¬ 
ing  them.  The  upfront  planning  should  take  on  a  three-fold  emphasis:  first,  each  weapon  system 
to  be  developed  should  incorporate  adequate  design  for  testability;  second,  AFLC  should  strive 
to  get  “smart”  ATE  with  ample  documentation  to  allow  untutored  people  to  use  the  ATE;  and 
third,  AFLC  should  apply  emphasis  to  use  as  few  ATE  systems  as  practical  to  limit  system  pro¬ 
liferation. 

•  Incorporate  adequate  design  for  testability.  This  suggestion  has  been 
offered  in  the  ATE  volume  of  the  Phase  I!  report  and  as  a  means  of 
weapon  system  quality  improvement.  In  summary,  design  for  test-ability 
requires  planning  within  early  design  phases  to  enable  the  weapon  system 
state  to  be  verified  as  operative  or  not.  Such  emphases  as  additional  and 
improved  BIT  and  the  MATE  concept  contribute  toward  this  suggestion. 

•  Acquire  smart  ATE.  Throughout  the  past  decade,  the  motivation  and 
intent  of  AFLC  was  to  acquire  ATE  that  did  not  require  highly  trained 
operators.  The  dependency  upon  the  ATE  itself  to  accomplish  testing 
was  prevalent;  however,  in  reality  the  delivered  ATE  systems  have 
migrated  toward  requiring  more  competent  personnel.  Breakthroughs  in 
microprocessors,  voice  synthesis,  improved  graphics,  interactive  soft¬ 
ware,  etc.  promise  to  provide  a  better  chance  of  acquiring  smart  ATE. 

o  Limit  ATE  proliferation.  Establishing  adequate  standards  and  empha¬ 
sizing  modularity  will  significantly  assist  in  this  area.  Success  with  this 
area  is  extensively  dependent  upon  improved  and  expanded  AFLC  plan¬ 
ning. 

Table  3-3  is  included  to  illustrate  the  problems  that  are  identified  with  ATE.  The  data  con¬ 
tained  therein  was  extracted  from  the  DOD  Industry/ Joint  Services  Automatic  Test  Project. 
Note  that  the  maintenance  planning  and  support  concepts  task  group  cited  virtually  every  pro¬ 
blem  listed.  There  is  little  question  that  improvements  in  upfront  planning  and  implementation 
is  the  most  significant  problem  pertinent  to  ATE  and  facing  AFLC  through  the  next  10  years. 
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3 . 2 .2 . 1  Extension  of  A1SF  Capability  to  the  Flight  Line 

Most  malfunctions  are  discovered  during  pre-operational  checks,  aircraft  preflight,  or  dur¬ 
ing  actual  operations.  During  pre-operational  checks  there  is  considerable  pressure  to  put  the 
system  online.  As  a  result  malfunction  symptoms  are  hurriedly  analyzed  and  one  or  more  boxes 
pulled  and  replaced.  There  is  little  time  for  fault  analysis  and  orderly  fault  isolation.  It  is  in  this 
dynamic  environment  that  highly  capable  ATE  has  its  greatest  benefit. 

The  reliability  of  built-in-test  (BIT)  check  will  increase  as  more  test  circuits  are  embeJded  in 
the  chip  itself,  it  will  become  easier  to  identify  and  replace  modules,  boards,  or  components.  On 
the  other  hand,  ATE  will  use  the  same  high-speed,  high  density  technology  to  increase  the 
capabilities  of  ATE  systems.  As  a  result  of  these  two  trends,  the  distinction  between  BIT  ana 
ATE  will  become  less  prominent. 

The  trend  of  ATE  during  the  1990’s  will  also  be  toward  more  flight  line  test  capability  such 
as  that  demonstrated  at  SM-ALC  for  the  F/FB-111.  Another  example  is  the  flight  line  test  set 
(FLTS),  currently  in  early  development  stages,  which  is  the  largest  scale  excursion  into  this  area. 
This  piece  of  flight  line  AGE  is  intended  for  system  testing  of  ?  subset  of  electronic  warfare 
systems.  The  success  of  this  program  will  undoubtedly  determine  the  extent  of  futute  endeavors 
of  this  kind.  Additional  flight  line  AGE  could  conceivably  be  utilized  for  other  avionics  subsets 
or  specialized  testing  where  costs  of  such  equipment  can  be  justified.  This  could  also  be  extended 
to  different  levels  of  tests  where  system  access  permits.  This  suggests  the  extention  of  in 
termediate,  depot,  and  1SF  capabilities  to  the  flight  line.  Further,  with  increased  communication 
capability,  a  problem  solving  link  would  exist  between  these  facilities  and  flight  line  activities. 
To  be  most  useful,  the  following  characteristics  are  necessary  in  flight  line  ATE  of  the  future. 

•  Modular.  It  must  interface  with  and  between  the  unit  under  test  a  wide 
variety  of  stimulus  and  measurement  devices. 

•  Functional.  It  must  surround  the  unit  under  test  with  an  input-output 
environment  closely  simulating  the  one  in  which  it  will  actually  operate. 

Stimulus  signals  and  responsive  measurements  must  be  real  time 
duplicates  of  those  used  by  the  systems. 

•  Flexible.  It  must  be  easily  reprogrammable  so  that  it  can  respond  quickly 
to  unit  under  test  design  changes  or  operational  conditions. 

•  Human  Engineered,  It  must  be  easily  operated  by  other  than  highly 
trained  engineers.  When  possible  the  system  should  guide  the  operator 
through  the  test  steps  providing  tutorial  aid  when  required. 


The  ATE  design  concept  presented  iti  Section  3. 2. 2. 2  will  meet  the  objectives,  lake  advan¬ 
tage  of  the  available  technology,  meet  operational  requirements,  and  satisfy  following  ECS  sup¬ 
port  concepts  presented  in  Section  1 . 

•  Maximize  sharing  of  distributed  ECS  support  resources  by  use  of 
modular  integrated  ECS  support  facilities  and  standardized  automated 
ECS  support  tools. 

•  Manage  and  support  highly  integiated  ECS  dispersed  at  geographically 
separated  support  locations  by  establishing  a  system  for  cCS  manage¬ 
ment  and  technical  data  flow. 

•  Minimize  critical  ECS  engineering  and  scientific  okill  needs  by  optimiza¬ 
tion  of  organic  contractor  skill  mix  and  increase  the  use  of  organic  lower- 
skilled  ECS  personnel  by  automation  and  standardization  of  ECS  sup¬ 
port  processes  and  procedures. 

3. 2. 2. 2  A1SF  Extension  Development  Concept 

To  correct  a  system  problem  the  technician  or  engineer  must  identify  the  problem  to  resolve 
it  on  site.  Duplicating  the  problem  involves  reproducing  the  mode  where  the  initial  problem  was 
observed.  This  can  result  in  continually  repeating  sequential/proceaural  steps  used  in  the  opera¬ 
tional  environment.  All  this  troubleshooting  takes  time  and  experience;  therefore,  accurate  on 
site  analysis  at  the  time  the  problem  occurred  can  pay  nigh  dividend  in  terms  of  efficient  use  of 
persornel  and  resources.  Recognizing  that  it  is  not  yet  possible  to  troubleshooi  an  inflight 
malfunction  until  the  aircraft  returns  to  its  base,  efficiency  is  achieved  when  the  malfunctioning 
system  is  correctly  identified  and  replaced. 

There  is  a  correlation  between  flight  line  trouble  shooting  activities  and  problem  solving  in 
the  A1SF,  especially  when  the  technicians  and  engineers  are  dealing  with  transient  failures, 
multiple  time  dependent  failures,  or  application  dependent  failures.  Most  ATE  is  designed  to 
detect  and  diagnose  single  hard  failures  rather  than  those  associated  with  the  dynamic  execution 
of  an  applications  program.  To  diagnose  these  dynamic  problems,  the  technicians  or  engineers 
need  to  generate  a  dynamic  environment  which  stimulates  the  malfunctioning  software/ 
hardware.  This  common  need  tot  dynamic  stimulus  and  a  highly  capable  ECS  monitoring 
capability  ties  the  needs  of  the  fl’ght  line  technician  and  the  A1SF  engineer  together.  These  com¬ 
mon  needs  will  bring  about  a  closer  relationship  between  the  flight  line  and  the  A1SF,  especially 
to  solve  '‘bad  actor”  or  ‘‘cannot  reproduce”  repeated  failures. 

The  expanding  use  of  communication  satellites  and  communication  networks  will  allow 

direct  communications  between  the  A1SF  engineers  and  the  flight  line  technican.  By  using 

available  communication  tools  and  automated  flight  line  aids,  with  software  common  to  the 

support  1SF,  it  will  be  possible  to  create,  on  a  case-by-case  basis,  a  powerful  problem  solving 

team.  By  solving  problems  at  the  operational  site  it  will  be  possible  to  reduce  the  number  of 
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system  components  returned  to  the  depot  needlessly.  By  minimizing  the  number  of  components 
in  the  logistic  pipeline,  life  cycle  support  costs  can  be  reduced.  To  accomplish  improved  onsite 
testing,  field  level  units  must  have 

•  Improved  test  sets  capable  of  dynamic  inputs  and  interactive  measure¬ 
ments; 

•  Complementary  ATE  and  BIT  checks; 

•  Improved  operator  skills,  including  knowledge  of  system  operation; 

•  Improved  onsite  display  of  test  results,  including  graphic  displays;  and 

•  Fault  environment  snapshot  recording/transaction  capability. 

ATE  systems  designed  with  the  features  displayed  in  Figure  3-7  will  satisfy  the  above  objectives. 

Such  an  extendable  test  set  could  provide  the  following: 

•  Test  set  reprogrammable  to  satisfy  a  number  of  multilevel  requirements, 

•  Function  switches  programmable  to  match  the  test  program  or  test 
phases, 

•  Menu  driven  test  function  selection, 

•  Graphic  representation  of  the  test  cycle, 

•  Data  transmission  capability  for  interaction  with  intermediate,  and  depot 
for  the  1SF  support  systems, 

•  Dynamic  input/output  comparison, 

•  Vectored  probe  to  stimulate  on  chip  test  circuits,  and 

•  Graphic  and  text  display  capability  to  provide  self  instruction  and  help 
functions. 


3.2.3  Multi-ECS  Weapon  System  Support 

The  increased  emphasis  on  performance  of  the  tactical  forces,  the  drive  to  an  all¬ 
environment  force,  and  the  impact  of  technology  will  combine  to  increase  the  complexity  of  air¬ 
craft, and  the  use  of  ECS  in  multiple  applications.  These  factors,  in  turn,  will  place  increasing 
demands  on  the  AFLC  and  their  support  of  ECS.  New  systems  being  introduced  to  the  fleet  are 
being  installed  on  different  aircraft  (See  Table  3-4)  and  this  is  adding  significant  management 
and  logistics  burdens  to  the  AL.C’s.  The  problems  are  compounded  even  further  when  joint 
efforts  with  U.S.  allies,  such  as  on  the  F-16,  are  undertaken  or  when  support  to  foreign  coun¬ 
tries  is  provided,  as  in  the  case  of  the  F-4  aircraft. 


Table  3-4.  Projected  Multiple  Use  of  ECS 


There  are  a  number  of  initiatives  that  AFLC  should  take  to  alleviate  the  problems  that  will 
arise  from  the  multiple  use  of  ECS  on  different  aircraft  or  within  the  same  aircraft.  In  addition, 
increased  emphasis  on  initiatives  already  begun,  such  as  standardization,  can  reduce  the  impact 
of  supporting  the  multi-use  ECS.  This  section  presents  additional  initiatives  and  recommenda¬ 
tions  while  considering  the  impact  of  on-going  efforts  within  the  Air  Force.  It  also  highlights  the 
changing  nature  of  avionics  to  digital  systems  from  the  previous  analog  systems.  This  change  has 
required  the  ALC’s  to  take  r.ew  approaches  to  support  the  aircraft  and  avionics  on  board  the 
aircraft.  As  an  example,  Figure  3-8  shows  the  growth  versions  of  the  F-16  avionics  architecture. 
It  should  be  noted  that  the  cross-hatched  blocks,  which  comprise  a  major  number  of  the  com¬ 
ponents  of  the  integrated  avionics,  represent  digital  ECS.  This  expansion  over  the  avionics  on 
the  A  and  B  versions  of  the  aircraft  illustrates  how  rapidly  ECS  utilization  is  increasing.  By 
referring  to  Table  3-4,  an  indication  of  the  number  of  ECS  the  F- 1 6  will  share  with  other  aircraft 
can  be  observed. 

The  approach  taken  here  is  to  logically  examine  the  factors  that  have  a  primary  bearing  on 
the  ALC’s  support  posture  as  a  result  of  multi-use  ECS,  postulate  a  set  of  approaches  to  resolve 
problems  caused  by  these  factors,  and  then  use  real  examples  to  establish  the  validity  of  the 
approach  or  initiative.  Several  of  the  initiatives  are  directed  at  the  software  contained  in  the 
ECS,  since  one  of  the  prime  motivators  in  going  to  digital  technology  is  the  relative  ease  with 
which  it  can  be  changed  to  meet  changing  operational  requirements  (e.g.,  the  digital  processing 
of  signals  based  on  threat  information  in  the  electronic  warfare  environment,  and  the  weapons 
release  algorithms  as  new  weapons  come  into  the  inventory).  Figure  3-9  illustrates  an  idealized 
approach  to  establishing  the  solutions  to  multi-use  ECS  problems.  For  the  1990’s,  however,  in¬ 
puts  such  as  operational  requirements  are  not  totally  clear  and,  thus,  may  play  a  lesser  part  in 
earlier  studies. 

3 . 2 . 3 . 1  Support  Requirements  for  Multi-Use  ECS 

The  support  requirements  for  multi-use  ECS  must  provide  for  the  integrity  of  the  avionics 
system  on  board  a  specific  aircraft  while  minimizing  support  costs  due  to  test  facilities,  person¬ 
nel,  and  training.  The  cost  of  replicating  simulation  facilities  at  different  locations  because  the 
system  managers  for  the  various  a  rcraft  are  at  different  locations  can  be  exorbitant.  The  item 
and  system  managers  are  physically  separated  in  many  cases  and  ideologically  separated  in 
others.  The  physical  separation  is  by  far  the  most  restrictive,  however,  because  it  compounds  the 
con  xity  of  supporting  a  system.  Potential  solutions  exist  to  reduce  the  impact  due  to  multi- 
ECS  use.  Standardization  of  architectures,  both  instruction  set  as  in  the  1750A  or  the  new 
military  computer  family  (MCF)  and  the  1553  bus  architectures,  are  important  to  reducing  sup- 
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port  costs  tor  future  aircraft.  These  standardization  issues  as  they  impact  multi-use  ECS  are 
addressed  in  subsequent  paragraphs  of  this  section. 

The  criteria  for  assigning  an  ECS  to  an  item  manager  or  system  manager  is  not  self  evident, 
but  several  factors  have  promise  as  technical  measures  that  will  assist  in  the  assignment  decision. 

Many  ECS  are  integral  parts  of  a  closely-coupled  system  which  will  possibly  preclude 
separation  of  ECS  from  a  sensor  or  a  second  ECS  system  from  an  integrity  standpoint.  Closely- 
coupled  is  defined  as  two  ECS  or  ECS  and  sensor  combinations  which  provide  feedback  to  one 
another.  Examples  of  closely-coupled  systems  are  the  radar  altimeter  and  operational  flight 
systems  on  the  cruise  missile  and  the  radar  and  fire  control  computer  on  the  F-16  system. 

However,  it  does  not  automatically  follow  that  because  an  ECS  is  part  of  a  closely-coupled 
system,  that  it  should  be  assigned  to  the  system  manager.  Historically,  the  inertial  measurement 
unit  (IMU)  used  on  board  an  aircraft  is  modeled  in  software  in  simulation  facilities  because  of 
the  difficulty  in  driving  a  platform  designed  to  provide  inputs  to  the  IMU  as  a  function  of  the 
simulation.  Platforms  are  used  but  they  are  generally  independent  of  the  hot  bench  and 
specifically  designed  to  test  only  the  IMU.  A  secondary  factor,  then,  that  would  be  developed  as 
criteria  for  ECS  assignment,  is  the  complexity  of  the  closed-loop  system  or  the  capability  to 
simulate  the  ECS  or  sensor.  The  more  complex  a  system  in  terms  of  signal  processing  and  inter¬ 
face  to  other  ECS  in  the  closed-loop  system,  the  more  difficult  it  is  to  model  in  a  host  computer 

with  a  simulation  facility  and,  consequently,  the  greater  the  need  for  the  subject  embedded  com- 
* 

puter  to  be  in  the  trainer,  the  avionics  integration  facility,  or  the  item  test  stand. 

Timing  constraints  between  two  or  more  ECS  in  an  integrated  system  is  one  of  the  primary 
factors  that  increases  complexity  significantly.  Two  systems  which  pass  data  continuously  and 
have  required  rapid  responses,  or  enter  data  via  Direct  Memory  Access  (DMA)  will  present 
problems  in  an  Avionics  Simulation  Facility  if  the  actual  hardware  is  not  employed,  especially  if 
the  data  is  input  via  direct  memory  access.  This  will  probably  be  the  case  in  many  EW  sensors 
and  ECS  combinations.  The  question  of  data  freshness  is  also  important  when  a  continuous 
data  stream  is  modeled  in  a  simulation.  The  data  may  be  fed  to  a  dig  V  filter,  and  the  response 
of  the  filter  or  of  a  function  to  a  discrete  signal  in  the  continuous  date  -tream  may  be  incorrectly 
interpre'ed  during  software  modifications  and  checkout  if  the  signals  are  incorrectly  modeled.  A 
closer  examination  of  current  and  projected  systems  that  provide  data  directly  to  ECS  or  where 
high  data  rates  or  closed-loop  interactions  are  required  should  be  undertaken  to  establish 
specific  criteria  for  using  hardware  in  an  A1SF.  The  evolving  standards  for  bus  architecture  will 
provide  a  more  standard  interface  in  the  future,  but  modernization  programs  on  older  aircraft 
and  sensors  will  dictate  the  need  for  hardware-to-hardware  interfaces  in  AISF’s  for  the 
foreseeable  future. 
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Interrupt  driven  systems  may  be  more  easily  separated  from  other  ECS  systems  if  the  inter¬ 
rupts  follow  random  patterns,  because  the  checking  of  software  that  responds  to  the  interrupts 
may  be  done  with  models  employing  Monte  Carlo  techniques  or  by  systematically  checking 
sequencing  and  timing  of  the  software  that  should  respond  to  the  interrupt.  If  the  traffic  bet¬ 
ween  embedded  computer  systems  is  light,  the  support  requirements  are  diminished.  Light 
means  total  traffic,  since  a  few  signals  at  a  very  high  rate  can  impose  severe  processing  re¬ 
quirements  on  an  embedded  computer  system. 

Another  consideration  in  the  assignment  of  an  ECS  and  also  in  the  determination  of 
whether  an  ECS  should  be  included  in  a  simulation  facility  is  the  built-in  test  (BIT)  incorporated 
in  the  ECS.  Built-in  test  is  required  in  ECS  and  frequently  features  wrap-around  signals  to  buf¬ 
fers  and/or  sensors  that  are  difficult  to  model  in  a  simulation  facility. 

Recommended  Action 

Conduct  a  study  of  closely-coupled  ECS  and  of  projected  sensors  and  ECS  to  determine  if 
criteria  can  be  established  which  will  aid  in  establishing  ECS  assignments  and  whether  the  actual 
hardware  should  be  included  in  simulation  facilities  for  avionics  integration,  operational  flight 
program  development,  trainers,  and  electronic  warfare.  Factors  to  consider  are  the  types  and 
timing  to  interfaces,  the  nature  of  the  processing  on  the  signals,  the  amount  of  interrupt  process¬ 
ing,  the  built-in  test  requirements,  standardization,  functions  of  the  ECS,  and  traffic  flow. 

The  assignment  of  an  ECS  to  <m  item  manager  will  not  automatically  mean  that  a  system 
manager  charged  with  ensuring  that  a  distributed  processing  system  composed  of  two  or  more 
embedded  computers  will  not  require  the  ECS  assigned  to  the  item  manager  to  be  duplicated  in 
an  avionics  integration  facility.  As  previously  stated,  there  are  numerous  factors  that  will  deter¬ 
mine  whether  ECS  support  is  required  at  both  an  item  manager  and  system  manager  level, 
though  there  appear  to  be  technical  considerations  warranting  further  study  to  minimize 
duplication  of  facilities.  In  addition,  subsequent  discussions  will  examine  the  extent  of  emula¬ 
tion  of  ECS  in  trainers  and  integration  support  facilities. 

3. 2. 3. 2  Emulation  in  Multi-Use  ECS 

Great  strides  are  being  made  in  emulating  computers  and  the  ALC’s  are  actively  developing 
an  emulation  capability.  There  are  Nano-Data  QM-1  emulation  computers  at  WR-ALC  and 
OC-ALC  and  plans  are  underway  to  emulate  a  target  computer  at  SM-\LC.  In  addition,  an 
emulation  using  special  boards  on  the  VAX  11-780  is  underway  on  the  ALQ-131  verification  and 
validation  program.  Research  is  underway  in  the  use  of  microprocessors  for  emulation.  WR- 
ALC  now  has  a  higher  order  language  compiler  for  the  QM-1  on  the  Univac  1108  computer 
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which  can  speed  the  development  of  a  specific  emulation  of  a  target  computer.  The  use  of 
emulations  instead  of  actual  ECS  in  selected  applications  has  the  potential  of  reducing  support 
costs  and  also  minimizing  scheduling  problems.  The  primary  concern  in  using  an  emulation  to 
computers  generally  can  introduce  execution  times  different  from  the  actual  embedded  com¬ 
puter  and  consequently,  limits  the  checkout  of  timing  and/or  interfaces.  However,  the  actual 
software  for  the  ECS  is  run  and  the  sequencing  and  logic  of  the  real  computer  is  followed. 

The  ability  to  use  emulations  instead  of  the  actual  computer  could  produce  a  number  of 
positive  benefits  in  support  of  multi-use  ECS  and  aircrew  training  devices  concurrent  with 
operational  flight  programs.  Figure  3-10  illustrates  how  this  could  be  achieved.  The  item 
manager  would  effect  the  block  update  of  an  OFP  on  an  independent  stand  and  tapes  would  be 
distributed  to  the  trainer  sites  and  to  AISF’s  in  the  multi-use  environment  for  integration  and 
test.  Of  course,  the  actual  hardware  in  each  facility  would  be  even  better,  but  hardware 
availability  and  cost  can  make  this  difficult  to  achieve.  The  initial  set  of  hardware  requirements 
should  include  test  stand  requirements  if  actual  hardware  is  to  be  used.  Emulation  costs  may  be 
significantly  cheaper  on  a  life  cycle  basis.  It  provides  the  vehicle  to  centralize  support  of  an  ECS 
with  one  ALC.  The  responsible  organization  would  be  charged  witn  updating  the  OFP,  hard¬ 
ware,  and  the  emulations.  Scheduling  of  changes  to  the  mulii-use  ECS  would  also  be  the  respon¬ 
sibility  of  the  item  manager  in  the  sample  chosen.  Since  the  resources,  including  expertise,  are 
resident  in  one  location,  changes  can  be  accomplished  to  all  aspects  of  the  ECS  and  limited 
testing  against  hardware  performed  prior  to  being  incorporated  into  weapon  systems  or  aircrew 
training  devices.  The  organization  responsible  for  maintaining  the  OFP  would  also  be  responsi¬ 
ble  for  maintaining  the  emulation. 

Recommended  Action 

An  experiment  should  be  developed  using  emulations  of  an  existing  ECS  that  will 
demonstrate  the  feasibility  of  using  emulations  for  multi-use  ECS.  Consideration  snould  be 
given  to  incorporating  the  emulation  in  an  AISF  and  a  corresponding  ATD  to  establish  whether 
concurrency  is  possible  using  emulations.  The  impacts  of  timing  discrepancies  between  the 
emulation  and  the  actual  embedded  computer  execution  should  be  explored  and  boundaries  of 
acceptable  deviations  established.  Life  cycle  costing  of  the  two  options  (emulation  versus  ECS 
use)  should  be  derived  and  compared  to  establish  costing  estimates.  Microprocessor  emulations 
should  be  used  in  the  experiment  because  microprocessors  potentially  offer  a  cheaper  alternative 
for  aircrew  training  devices.  The  QM-1  poses  a  significant  initial  investment  if  the  emulation 
capability  will  be  necessary  in  several  physical  locations. 
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3. 2. 3. 3  Architectures  and  Standards  in  Multi-Use  ECS 


Standardization  offers  increased  support  capabilities  for  reduced  resources  because  it 
potentially  provides  plug-compatible  hardware  systems,  reduces  the  disciplines  or  reservoir  of 
knowledge  required  to  support  systems,  and  makes  software  more  transportable.  To  achieve  the 
desired  support  posture  in  the  1990’s,  AFLC  should  assess  the  impact  of  the  standardization  of 
embedded  computer  architecture,  bus  structures,  data  bases,  language,  graphics  systems, 
AISF’s,  networks,  documentation,  and  development  standards.  The  Air  Force  is  making  pro¬ 
gress  toward  standardization  (e.g.,  the  RD/LE  policy  letter  of  26  April  1981)  which  establishes 
standards  for  languages  and  instruction  set  architectures  for  16-  and  32-bit  machines. 

The  standards  currently  being  developed  for  military  applications  (M1L-STD  1750  instruc¬ 
tion  architecture  set,  Ada  language,  AFR  800-14)  are  oriented  to  the  development  of  the  tactical 
system  with  insufficient  consideration  being  given  to  their  impact  on  support  requirements.  For 
example,  computer  architectures  could  be  designed  with  interface  boards  that  will  permit  a  stan¬ 
dard  programmable  computer  monitor  and  control  (CMAC)  device  to  connect  to  the  computer 
through  and  AGE  port  or  in  a  unique  port  to  the  computer.  Too  often,  unique  CMAC’s  have  to 
be  designed  and  developed  for  each  embedded  computer  in  the  A1SF.  The  same  ports  that 
would  be  used  for  the  CMAC  in  a  test  stand  would  also  be  used  in  flight  test  aircraft  for  data 
collection  which  would  also  reduce  development  and  test  costs.  Because  a  multi-use  ECS  would 
be  designated  to  different  aircraft.'a  standard  interface  would  serve  both  with  modifications 
perhaps  due  to  cable  lengths  (i.e.,  line  driver  changes),  cooling,  or  power  requirements.  Figure 
3-11  illustrates  how  an  ECS  with  standard  interface  board  to  a  programmable  CMAC  would 
promote  multiple  uses.  The  advent  of  very  high  speed  integrated  circuits  (VHS1C)  can  result  in 
devices  like  the  programmable  CMAC’s  becoming  more  standard  as  chip  densities  and  speeds 
are  increased.  Similary,  the  disadvantages  of  standard  computer  architectures  in  terms  of  speed, 
size,  and  power  requirements  may  be  offset  as  parallelism,  direct  memory  access,  input/output 
instruction  sets,  and  modules  that  fit  embedded  computer  requirements  are  incorporated  into 
the  standards. 

The  standard  interface  for  a  programmable  CMAC  is  just  one  example  of  how  standardiza¬ 
tion  can  impact  support  of  ECS.  Another  area  deserving  attention  is  standards  for  engineering 
data  management.  The  engineering  data  management  system  (EDMS)  developed  by  WR-ALC 
for  the  F-15  is  a  prime  candidate  for  exportation  to  other  weapon  systems  and  ALC’s.  The  use 
of  a  proprietary  data  base  management  system  (TOTAL)  and  smart  terminals  was  valid  for  the 
F-15  or  any  other  multi-use  weapon  system  at  WR-ALC  (e.g.,  PAVE  TACK)  but  increases  the 
cost  of  adapting  it  to  other  ALC’s  that  don’t  have  the  license  for  TOTAL,  an  Interdata- 
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equivalent  host  computer,  or  the  Hewlitt-Packard  Smart  Terminals.  Once  adapted  for  a  multi¬ 
use  ECS  such  as  PAVE  TACK,  it  is  logical  to  extend  it  to  th?  weapon  systems  that  use  PAVE 
TACK  to  maintain  a  common  data  base.  The  costs  of  each ,  though,  must  be  weighed  against 
additional  development  costs  which  generally  accrue  as  development  goals  are  made  more 
general.  Certainly,  the  fact  that  EDMS  works  ana  is  relatively  easy  to  transport  has  to  weigh 
heavily  for  its  adaptation  as  a  standard.  The  classic  case  of  being  too  general  is  O/S-360,  as 
discussed  by  Brooks  in  The  Mythical  Man  Month.  There,  the  drive  for  a  general-purpose 
opertating  system  for  the  IBM-360  increased  the  complexity  and  development  costs  significant¬ 
ly.  The  major  point  is  that  a  standard  engineering  da. a  management  system  is  evolving  within 
the  ALC  community  and  that  the  ALC’s,  in  conjunction  with  AFLC,  are  capable  of  developing 
standards  and  standard  systems  for  logistics  support  ECS.  This  capability  should  be  applied  to  a 
wide  range  of  areas  such  as  computer  architecture,  languages,  documentation,  support  tools, 
and  management  directives. 

Other  examples  of  items  that  should  be  considered  for  standardization  nclude  the 
following; 

•  Terminals  used  with  AISF’s,  since  smart  terminals  may  actually  reduce 
development  costs  because  of  built-in  features.  Reduced  development 
costs  could,  however,  be  offset  by  increased  rehost  costs  if  the  system  is 
to  be  transportable  to  different  mainframes. 

•  Simulation  host  computers  and/or  languages  may  become  standardized 
into  categories  (e.g.  16-,  24-,  32-bit  word  lengths)  making  transportabil¬ 
ity  of  real-time  or  support  software  more  readily  accomplished.  This 
standardization  should  be  considered  for  aircrew  training  devices  as  well 
as  for  operational  flight  program  support  facilities  to  promote  maintain¬ 
ability.  The  languages  for  many  aircrew  training  devices  now  in  existence 
are  arcane  (e.g.,  the  F-4)  and,  consequently,  changes  are  difficult  to 
make. 

Embedded  Computer  Systems  that  art  used  in  more  than  one  aircraft  (e.g.,  PAVE  TACK, 
LANTIRN,  ARN-101,  etc.)  or  in  different  versions  of  the  same  aircraft  (e.g.,  ARM-101  in  the 
F-4E  and  RF-4C,  IBM  4  pi  in  the  F-l  1  ID  and  FB-11 1  A)  have  many  common  software  compon¬ 
ents.  Because  of  different  aircraft  roles,  sections  of  the  software,  most  commonly  in  the 
input/output,  may  be  different.  Modular  design  and  development  of  the  software  can  result  in 
modifications  to  the  ECS  being  isolated  to  small  portions  of  the  total  software/hardware.  For 
example,  if  the  I/O  is  placed  in  a  common  block  within  the  computer,  then  changes  to  the  I/O 
have  a  lesser  impact  on  the  program  itself  and  on  the  support  systems  for  the  ECS.  By  isolating 
the  portions  of  the  ECS  that  are  most  likely  to  change  through  computer  architecture  and/or 
software  structure,  the  impacts  of  using  that  ECS  in  multiple  applications  can  be  minimized. 
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There  are  many  AISF’s,  ATD’s,  and  EW  systems  either  completed  or  under  development 
and  little  similarity  between  soft  ware  modules  in  the  AISF’s  even  though  an  ECS  used  on  multi¬ 
ple  aircraft  may  be  involved  ir.  more  than  one  A1SF.  While  different  aircraft  have  different 
characteristics,  it  may  be  possible  for  one  model  with  different  coefficients  to  represent  several 
aircraft.  Similarly,  the  sensor  item  manager  may  be  able  to  develop  a  module  in  a  HOL  with 
variations  that  can  be  implemented  on  the  AISF’s  that  require  the  sensor  model.  The  best 
approach,  given  the  rapid  advance  in  microprocessors,  may  be  to  develop  the  models  on  a 
microprocessor  that  would  be  plug-compatible  in  a  distributed  AISF.  This  may  have  the  effect 
of  minimizing  changes  in  software  and  also  takes  advantage  of  standardized  interfaces.  The  size 
of  a  central  processing  unit  (CPU)  to  host  the  common  software  could  be  reduced.  Transporta¬ 
bility  of  the  software  via  microprocessors  would  also  be  enhanced. 

Recommended  Action 

The  AFLC  should  initiate  a  series  of  studies  to  examine  the  architectural  innovations/struc¬ 
ture  that  will  promote  testability  and  supportability  of  ECS.  The  studies  should  formulate  a 
baseline  of  data  and  expertise  within  AFLC  that  would  enable  AFLC  to  shape  standards  and 
impact  developments  to  increase  testability  and  supportability.  Specific  areas  that  should  be 
examined  include:  interface  ports  to  be  used  for  test  tools  such  as  programmable  CMAC,  the 
input/output  structure  for  not  only  the  MIL-STD  1553  bus  but  also  direct  memory  access  of 
high  frequency  or  continuous  data  streams,  software  language  development  for  ECS  and  sup¬ 
port  systems,  life  cycle  cost  effects  of  incorporating  the  support  features,  standardized  modules 
for  aircraft  or  sensor  modules  including  plug-in  microprocessors,  and  modularity  innovations  in 
hardware  and  software  that  isolate  a  change  to  a  specific  section  of  the  ECS.  This  initiative 
would  require  some  research  and  development,  but  the  emphasis  is  on  increasing  the  supporta¬ 
bility  of  transitioned  ECS  by  changing  ECS  design  concepts. 
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4.  PROGRAMMATIC  INITIATIVES 


The  previous  section  discussed  recommended  administrative  initiatives  in  the  general  areas 
of  management  and  engineering  practices  and  acquisition  and  support  practices.  While  the 
administrative  initiatives  are  primarily  in  the  overall  policy  and  guidance  domain,  they  are  very 
closely  related  to  the  initiatives  addressed  in  this  section  and  their  implementation  essentially 
establishes  the  direction  and  framework  for  addressing  the  spectrum  of  ECS  support  during  the 
1980’s.  All  of  the  recommended  initiatives  are  aimed  at  elimination  of  current  and  projected 
deficiencies;  however,  the  programmatic  initiatives  in  some  cases  have  the  additional  dimension 
of  accommodating  existing  resources  (equipment  and  facilities)  committed  to  the  various  ECS 
categories,  and  are  designed  to  capitalize  and  build  upon  this  investment.  The  entire  approach  is 
based  upon  attacking  ECS  support  problems  on  a  broad  front  with  both  administrative  initia¬ 
tives  and  deliberate  and  measured  steps  in  the  form  of  definite  programs  over  a  period  of  time. 

The  following  four  programmatic  initiatives  are  described  in  this  section. 

•  Automation  and  Standardization  of  ECS  Support  Processes  (Section 
4.1) 

•  Modular  Extendable  Integration  Support  Facilities  (Section  4.2) 

•  ECS  Readiness  Support  (Section  4.3) 

•  ECS  Support  Networks  (Section  4.4) 

Individual  and  summary  implementation  detail  for  each  recommended  initiative  in  terms  of 
tasks,  resources  and  schedules  is  presented  in  Section  5. 

4.1  AUTOMATION  AND  STANDARDIZATION  OF  ECS  SUPPORT  PROCESSES 

Rapid  increases  in  computer  hardware  capability,  coupled  with  its  decreasing  size,  weight, 
and  cost  have  caused  a  trend  toward  employment  of  embedded  computers  in  virtually  all  new 
weapons  systems.  At  the  same  time,  increased  weapon  system  complexity  and  performance 
requirements,  along  with  increased  ECS  hardware  capability,  has  resulted  in  increased  ECS  soft¬ 
ware  size  and  complexity.  This  increase  in  ECS  software  volume  causes  ECS  support  productiv¬ 
ity  improvements  to  be  an  essential  element  in  control  of  the  accelerating  ECS  support  costs. 

It  was  noted  in  the  ECS  Support  Study  Phase  II  Report  (Volume  III  through  VII)  that  cur¬ 
rent  ECS  support  processes  are  manpower  intensive,  and  in  the  aggregate  utilize  a  proliferation 
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of  nonstandard  support  tools,  procedures,  and  nomenclatures.  The  deficiencies  noted  were 
summarized  in  Section  2  of  this  volume.  The  following  types  of  standardized,  automated  soft¬ 
ware  tools  are  recommended  to  eliminate  those  deficiencies  and  increase  ECS  support  process 
productivity. 

•  Software  documentation  system 

•  Configuration  management  system 

•  Data  base  management  system 

•  Management  information  system 

•  Software  repository 

•  Improved  ECS  analysis  tools  (simulations,  diagnostic  emulations) 

•  Comprehensive  software  development,  maintenance,  and  test  tools 

(specification  development  system,  editors,  code  syntax  checkers, 

scenario  generators,  1SF  and  operational  test  data  reduction  software, 
etc.) 

To  achieve  maximum  manpower  productivity  increase,  tools  must  be  designed  for  ease  of 
operator  interface.  This  means  that  tool  design  must  incorporate  HELP  and  tutorial  features  as 
well  as  menu  selection  techniques.  Properly  built  tools  used  by  large  numbers  of  people  should, 
to  as  great  an  extent  as  practical,  be  self-instructing  to  the  user.  Similarly,  user  interface  devices, 
such  as  terminals,  should  be  designed  with  standard  keyboard  layouts  and  with  standard  control 
codes. 

In  Section  4.1.1,  some  factors  affecting  development  of  software  support  tools  are  dis¬ 
cussed.  Management  support  tools  are  discussed  in  Section  4.1.2,  and  tools  which  support  the 
software  developmental  process  are  covered  in  Section  4.1.3.  A  summary  of  Ada  language  sup¬ 
port  environment  (support  system)  is  presented  in  4.1.4.  Finally,  key  AFLC  actions  leading  to 
development  of  improved  support  tools  are  discussed. 

4.1.1  General  Considerations 

The  AFLC  ECS  support  system,  which  is  intended  to  increase  productivity  of  the  ECS  sup¬ 
port  practitioners,  is  envisioned  to  be  a  loosely  coupled  set  of  standard  tools  with  predefined 
interfaces  to  allow  easy  inter-tool  communication.  The  tools  should  be  able  to  operate  in  stand¬ 
alone  support  of  specific  ECS  support  processes  as  well  as  in  concert  to  support  the  generic  ECS 
change  process.  Communication  between  tools  should  be  achieved  by  designing  each  tool  to 
generate  standard  format  output  files  which  are  accessible  by  other  tools.  The  total  set  of  ECS 
support  process  automated  tools  will  make  up  the  ECS  support  system. 
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Automated  support  tools  can  be  rehosted  to  a  locally  available  computer  at  each  project 
location  or  hosted  in  a  central  computer  system  with  user  access  by  network.  Tools  should  be 
designed  to  be  hosted  on  a  standard  computer  at  each  ALC  (perhaps  an  AFLC  network  inter¬ 
face  computer)  or  built  with  specific  design  constraints  to  facilitate  rehosting.  The  hosting 
approach  needs  to  be  determined  based  on  a  detailed  requirements  analysis  during  the  system 
definition  phase.  Factors  to  consider  in  determining  the  hosting  approach  include 

•  Cost  of  data  communication  versus  cost  of  computational  hardware  for 
each  approach, 

•  Cost  of  rehosting  the  tools  on  a  variety  of  local  computers  versus  cost  of 
standard  computers, 

•  Selection  of  a  hosting  method  that  is  transparent  to  the  user,  and 

•  Standardized  tools  regardless  of  hosting  approach. 

It  is  anticipated  that  data  communications  cost  will  continue  to  drop,  but  not  as  rapidly  as 
digital  processing  costs.  If  locally  used  tools  are  centrally  hosted,  the  network  and  central  com¬ 
puter  need  to  be  sized  for  peak  loading  to  prevent  delays  and  to  keep  the  hosting  method 
transparent  to  the  user.  Additional  costs  will  be  incurred  if  it  is  necessary  to  rehost  each 
enhancement  of  the  tools  on  a  wide  variety  of  locally  available  computers.  Standardization  of 
tools  is  an  important  goal,  but  standardization  of  tool  interfaces  and  file  formats  is  required  to 
allow  some  level  of  necessary  tool  communications. 

A  prerequisite  to  increased  standardization  of  ECS  support  tools  is  greater  standardization 
of  ECS  support  piocesses.  Support  process  and  tool  standardization  will  cause  lesser  numbers  of 
support  tools  to  be  required.  The  end  result  is  that  investments  in  support  tools  can  be  concen¬ 
trated  on  the  decreased  number  of  tools  needed,  and  higher  quality  software  support  systems 
can  be  developed. 

The  RD/LE  letter  of  25  April  1981  on  the  subject  of  Standardization  of  Embedded  Com¬ 
puter  Resources  is  an  important  step.  This  letter  states  that  .1-73  will  be  the  standard  language 
for  avionics  systems  until  Ada  is  available  (about  1984),  and  that  Ada  will  be  the  preferred 
language  for  all  ECS  when  it  is  sufficiently  mature.  It  also  states  a  goal  of  standardization  of  16 
bit  (M1L-STD-1750)  and  32  bit  (M1L-STD-1862)  Instruction  Set  Architectures  (ISA’s)  for  other 
than  ATD  and  ATE  systems.  Preliminary  data  on  the  Ada  support  system  (support  environ¬ 
ment)  indicates  that  it  will  meet  most  identified  Ada  language  support  needs.  The  Ada  support 
environment  now  being  built  is  scheduled  to  be  completed  by  1984. 


4-3 


An  AFLC  software  support  system,  which  is  intended  to  increase  manpower  productivity 
and  allow  usage  of  lower  skilled  personnel  through  automation  of  support  processes,  should 
contain  the  types  of  software  support  and  management  tools  listed  in  Table  4-1.  This  software 
support  system  is  needed  for  currently  fielded  ECS.  Examples  of  tools  which  would  comprise 
the  ECS  support  system  are  discussed  in  Sections  4.1 .2  and  4.1 .3. 

4. 1 .2  Automated  Management  Support  Tools 

Tools  addressed  in  this  section  are  those  whose  function  is  to  support  AFLC  in  fulfilling  its 
life  cycle  management  support  responsiblity  for  ECS  systems.  These  tools  consist  of  a  Data  Base 
Management  System  (DBMS),  a  Configuration  Management  System,  and  a  Management  Infor¬ 
mation  System  (MIS).  Also,  there  is  a  need  for  locally  available  tools  hosted  on  a  microcompu¬ 
ter  at  individual  project  locations  to  allow  quick  access  and  to  bridge  the  gap  between  hand 
calculator  and  mini  computer  capabilities. 

4. 1 .2. 1  Data  Base  Management  System 

A  DBMS  is  considered  an  essential  element  of  a  software  support  system.  It  is  used  to  col¬ 
lect  and  maintain  management  and  engineering  data,  such  as  test  scenarios,  test  results,  software 
ancestry  files,  tool  version/modification  status,  simulation  data  bases,  project  schedules,  and 
resources.  The  DBMS  will  provide  a  transparent  interface  between  the  user  and  the  data  storage 
hardware  where  the  various  AF1  C  ECS  support  system  tools  reside.  It  allows  more  complex 
relationships  between  data  base  elements  than  is  normally  available  on  mini-computer  systems. 

4. 1 .2.2  Configuration  Management  Tools 

Configuration  management  problems  were  one  of  the  most  universal  ECS  support  deficien¬ 
cies  identified  in  Phase  II  of  the  ECS  Support  Study.  Configuration  Management  Techniques 
for  ECS  tend  to  be  based  on  techniques  used  for  hardware.  Since  software  undergoes  frequent 
and  sometimes  rapid  (few  day  turnaround)  changes,  current  techniques  are  not  timely  and  arc 
person-power  intensive. 

Configuration  management  processes  are,  for  the  most  part,  currently  performed  manually 
or  with  the  aid  of  various  semi-automated  tools  of  limited  capability.  More  capable,  and  stan¬ 
dard  configuration  management  tools  which  build  configuration  data  bases  accessible  by 
management  through  an  MIS  would  be  very  helpful  in  alleviating  this  deficiency  by  making  con¬ 
figuration  data  more  readily  available.  One  capable  tool  is  the  Engineering  Data  Management 
System  (EDMS)  acquired  to  automate  configuration  management  of  the  ECS  system  in  the  F-15 
weapon  system.  While  certain  enhancements  are  needed  (Reference  20,  May  1981,  FOE  letter: 
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ECS  Management  Information  Support  System),  it  should  be  a  candidate  for  an  AFLC  stan¬ 
dard  CM  system.  This  management  visibility  also  allows  belter  management  control  to  assure 
that  CM  receives  proper  priority  at  the  working  level. 

A  standard  configuration  management  tool  will  interact  with  the  configuration  manage¬ 
ment  procedures  of  systems  which  employ  the  tool.  For  existing  systems,  the  Operational/Sup¬ 
port  Configuration  Management  Procedures  (O/S  CMP)  will  need  to  be  updated  to  reflect  tool 
operational  procedures  and  capabilities.  For  new  systems,  the  availability  of  a  standard  CM  tool 
with  standard  procedures  and  capabilities  will  provide  an  initial  baseline  for  O/S  CMP  genera¬ 
tion,  which  should  significantly  speed  O/S  CMP  development  and  signoff.  For  some  systems, 
CM  tool  capabilities  may  need  to  be  modified  or  enhanced  to  support  unique  requirements. 


4 . 1 . 2 . 3  Management  Information  System 

An  important  element  of  support  process  automation  and  standardization  is  a  Management 
Information  System  (MIS).  This  tool  should  gather  project  data  from  the  various  AFLC 
automated  tools  (e.g.,  provide  user  friendly  access  via  the  Data  Base  Management  System  to 
configuration  management  data,  project  simulation,  and  status  accounting  data,  etc.)  and, 
based  on  English  language-oriented  commands,  prepare  special  management  reports  to  provide 
needed  data  for  management  decisions.  An  AFLC  standard  MIS  would  be  even  more  beneficial 
if  an  AFLC  network  is  built,  which  would  allow  inter-AFLC'  access  by  authorized  personnel  to 
any  set  of  project  data. 


A  Management  Information  System  should  be  used  to  facilitate  flow  of  the  following  types 
of  management  information,  thereby  allowing  increased  AFLC  management  visibility. 

•  Sub-project  and  project  schedules  and  resources  employed 

•  Status  and  schedules  of  pending  or  in-process  weapon  system  changes 

•  Status,  schedule,  utilization,  users,  etc.  of  AFLC  support  systems 

•  Configuration  status  including  documentation  versions  and  test  cases 
associated  with  a  given  baseline 

Conceptual  requirements  for  a  standard  AFLC-wide  Management  Information  System  are 


•  The  MIS  should  be  capable  of  accessing  output  files  of  standard  project 
tools  and  building  a  predefined  set  of  management  reports; 

•  The  MIS  should  have  access  to  an  AFLC  network  for  gathering  project 
data  from  other  ALC’s; 

•  The  MIS  should  have  an  English  oriented  inquiry  language  to  allow  easy 
specification  of  custom  management  reports; 
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•  The  MIS  should  be  capable  of  tracking  personnel  assignments  and 
resources  employed  at  the  MME  level  (over  100  people,  large  numbers  of 
projects),  allowing  management  assessment  of  the  impacts  of  personnel 
reassignment;  and 

•  The  MIS  should  be  able  to  communicate  with  the  user  by  a  variety  of 
graphical  techniques,  such  as  PERT  and  GANTT  charts,  as  well  as  time 
and  effort  graphs,  budget  versus  expenditure  graphs,  etc. 

4. 1.2. 4  Local  Project  Tools 

A  need  exists  for  a  set  of  local  project  tools  which  are  interactive  and  readily  available  to  a 
local  smail  project  manager.  In  the  context  of  this  paragraph,  a  small  project  is  one  requiring 
perhaps  10  to  100  man  years  to  complete.  Ideally,  these  tools  should  be  locally  hosted  on  an 
inexpensive  microcomputer  system.  The  microcomputer  could  also  be  used  for  editing  and  inter¬ 
actively  updating  simulation  source  code  and  documentation,  as  well  as  for  running  small  user 
developed  scientific  analysis  programs. 

A  local  microcomputer  could  bridge  the  gap  between  minicomputer  and  hand  calculator 
analysis  capabilities.  A  minicomputer  is  relatively  powerful  but  often  not  available  in  the  project 
work  area.  Hand  calculators  are  readily  available,  but  have  very  limited  capability.  The  local 
microcomputer  would  extend  a  limited  minicomputer  type  of  analysis  capability  to  the  project 

work  area  at  low  cost. 

Conceptual  requirements  of  locally  hostable  management  tools  are  listed  in  Table  4-2.  The 
essence  of  these  requirements  is  that  the  tools  be  locally  available,  interactive  and  easy  to  use. 

4. 1.2. 4.1  Project  Simulation  Tool.  Typically,  project  planning  activities  begin  with  the  decom¬ 
position  of  project  requirements  into  an  activity  network  (e.g.,  PERT  network)  which  explicitly 
contains  sequential  dependency  data  on  the  various  activities  (which  activities  must  precede 
others).  Overall  resource  requirements,  schedules,  and  manloading  are  estimated  and  for  larger 
projects,  functional  groups  of  activities  are  assigned  to  lower  level  (subproject)  managers.  The 
project  manager  may  define  activities  to  a  level  in  which  many  person  years  of  effort  are 
required  to  complete  each  activity.  The  assigned  subproject  managers  need  to  plan  to  a  greater 
level  of  detail,  with  the  finest  level  of  planning  detail  (to  perhaps  a  few  person  days  per  activity) 
performed  by  the  managers  who  interface  directly  with  project  workers.  Various  automated  and 
manual  project  planning  and  control  tools  are  available  to  the  large  project  manager,  and  he  can 
afford  to  employ  considerable  resources  in  planning  support  to  arrive  at  a  competent  and  com¬ 
plete  overall  project  plan.  The  subproject  manager  can  afford  very  limited  resources  for  detailed 
project  planning  since  the  total  resources  at  his  disposal  are  limited.  Since  detailed  planning  is 
time  consuming,  and  automated  tools  are  usually  not  locally  available,  the  subproject  planning 
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Table  4-2.  Conceptual  Requirements  of  Small  Project  Tools 


Requirements 

Justification 

Interactive 

• 

Planning  is  iterative.  Batch  submittals 
with  slow  turnaround  time  cause 
unacceptable  planning  delays 

• 

Allows  quick  correction  of  incorrect 
data  entry 

Simple  and  Efficient 

• 

Tool  will  not  be  used  unless  it  reduces 

Data  Input 

the  manager’s  workload 

• 

Complex  data  input  increases  errors 
and  incorrect  results 

• 

Small  inexpensive  computer  systems 
can  be  used 

Clear  Graphical 

• 

Data  will  not  be  used  by  manager  if  it 

Identification  of 

Project  Priorities 

is  too  hard  to  interpret 

and  Schedule  Status 

• 

Data  will  not  be  understood  by  project 
personnel  unless  it  is  very  easy  to 
interpret 

Hardcopy  Reports 
Provided 

• 

Record-keeping  requirements 

Activity  Resources/ 

• 

Needed  to  track  progress  and  evaluate 

Schedule  to  Technical 
Progress  Correlated 

need  for  corrective  action 

frequently  dc  <.ot  get  performed  in  great  detail.  In  the  limited  number  of  eases  where  complete 
and  accurate  subproject  planning  is  performed,  it  is  frequently  not  maintained  adequately  to 
reflect  changes  in  project  requirements,  available  resources,  or  schedules.  A  plan  that  is  not 
maintained  to  reflect  current  realities  is  of  little  use.  The  end  result  can  be  that  the  subproject 
manager  undertakes  a  partially  planned  task  with  inadequate  resources  and  without  a  thorough 
understanding  of  priorities,  problems  and  risks.  The  observation  that  the  first  90  percent  of  the 
typical  software  project  takes  90  percent  of  planned  resources  and  schedule,  and  the  last  10  per¬ 
cent  takes  another  90  percent  of  planned  resources  and  schedule,  is  all  too  frequently  accurate. 

A  projecct  simulation  tool  would  provide  the  following  data/capabilities  to  project 
management. 

•  Provide  clear  identification  of  project  activities. 

•  Allow  rapid  update  of  the  project  plan  to  reflect  changes  in  project 
requirements  or  resources. 

•  Generate  predicted  milestone  schedules  for  upper  management  report¬ 
ing. 

•  Forecast  resource  requirements  by  category  of  resource. 

•  Allow  evaluation  of  the  consequences  of  alternative  management 
actions. 

•  Be  a  useful  training  aid  for  new  project  managers. 

A  project  simulation  tool  would  require  as  input  only  activity  network  data  (which  activities 
follow  others,  activity  duration,  and  resource  requirements).  The  manager  needs  to  have  this 
data  available,  with  or  without  a  project  simulation  tool,  to  effectively  manage  his  project. 

A  tool  with  the  capabilities  described  above  would  require,  at  minimum,  an  8-bit 
microcomputer  host,  with  about  48K  bytes  of  memory  and  online  data  storage  (perhaps  two 
mini-floppy  disc  drives)  for  a  project  of  up  to  100  person  years  in  size. 

4. 1.2. 4. 2  Project  Status  Accounting  Tools.  A  simple  project  status  accounting  tool  which  would 
allow  a  local  manager  to  track  activity  status,  resources  expended,  resources  needed  to  complete 
the  activity,  percent  activity  completion,  etc.,  would  be  useful  to  increase  management  visibility 
and  control  during  project  execution.  A  tool  such  as  this  would  require,  as  a  minimum,  an  8-bit 
microcomputer  host  with  two  mini-floppy  disc  drives  for  a  100  petson  year  project. 

4.1.3  ECS  Software  Change  Support  Tools 

In  the  past  decade,  there  has  been  considerable  effort  devoted  to  fabrication  of  software 
tools  designed  to  facilitate  improved  software  quality,  increase  productivity  and  reduce  cost. 
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These  tools  have  been  only  partially  satisfactory  because  the  support  they  provided  to  oft  ware 
practitioners  has  been  too  limited.  Most  of  these  tools  and  systems  of  tools  support  only  very 
limited  portions  of  the  total  software  maintenance  effort  and  ignore  other  areas.  Further,  these 
tools  typically  force  the  tool  user  to  adapt  to  limitations  imposed  by  deficiencies  in  tool  design 
and  in  the  philosophies  of  the  tool’s  creators.  This  results  in  tools  which  are  potentially  helpful 
but  not  being  used. 

This  situation  would  improve  if  the  software  support  tools  were  designed  to  be  contin¬ 
uously  supportive  to  the  user  in  his  actual  software  support  activities.  Integrated  software  sup¬ 
port  systems  (support  environment)  and  their  benefits  have  been  widely  discussed  in  literature, 
but  there  is  a  need  for  organized  research  leading  to  implementation  of  improved  systems. 
Development  of  an  AFLC  software  support  system  requires  the  synergistic  integration  of  a  col¬ 
lection  of  tools  which  provide  strong,  close  support  to  the  software  practitioner.  The  environ¬ 
ment  must  have  at  least  these  five  characteristics: 

•  User  friendliness, 

•  Reuseability  of  internal  components, 

•  Tight  integration  of  capabilities, 

•  Broad  applicability,  and 

•  Central  information  repository. 

Software  support  systems  must  accommodate  the  user  rather  than  forcing  the  user  to 
accommodate  the  system.  This  accommodation  must  include  the  usual  items:  clear  diagnostics, 
fail-safe  recovery,  easy-to-use  input  language,  and  help  and  tutorial  features,  but  the  system 
must  also  provide  direct  and  painless  support  to  the  user  in  performing  his  actual  day-to-day 
activities.  The  need  for  user  friendliness  applies  both  to  the  individual  tools  and  to  the  accessib¬ 
ility  and  useability  of  the  entire  package  of  tools.  Reuseability  of  internal  components  implies 
that  the  software  support  environment  is  flexible  enough  to  accommodate  different  and  chang¬ 
ing  user  needs.  Fast  efforts  to  collect  a  set  of  monolithic  tools  under  control  of  a  common  user 
interface  has  generally  been  inflexible  and  inefficient  in  meeting  diverse  and  changing  user 
needs,  and  in  addition  has  been  cumbersome  to  use.  Support  systems  must  be  integrated  via  a 
central  base  to  allow  the  output  of  one  tool  or  tool  fragment  to  be  directly  available  to  other 
tools  thus  reducing  the  user’s  burden  in  communicating  with  tools. 

There  are  many  different  dimensions  to  tool  capability  and  applicability.  Support  systems 
are  software  language  dependent  as  well  as  user  activity  dependent,  e.g.,  software  requirements, 
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definition,  software  development,  software  maintenance,  validation  and  verification,  and  soft¬ 
ware  management  all  have  different  requirements  although  individuals  tools  may  be  applicable 
to  more  than  one  of  these  different  sets  of  activities.  A  successful  AFLC  software  support 
system  should  be  limited  to  supporting  AFLC’s  management,  and  supporting  maintenance  and 
test  activities  in  perhaps  two  or  three  software  languages  (Ada  and/or  J-73,  and  ATLAS).  An 
ECS  software  support  system  for  problem  analysis,  requirements  definition, 
development/modification  of  ECS  software,  and  software  test  is  discussed  in  the  following 
paragraphs. 

4. 1.3.1  ECS  Documentation  Tools 

A  standard  set  of  AFLC  software  documentation  tools  would  be  a  significant  ECS  automa¬ 
tion  aid.  However,  maintenance  of  ECS  documentation  using  an  automated  tool  requires  that 
the  baseline  documentation  be  already  available  in  a  format  and  medium  acceptable  to  the  tool. 
This  tends  to  mean  that  the  documentation  must  be  initially  developed  using  the  tool  or  pro¬ 
cured  to  be  compatible  with  the  documentation  tools.  A  joint  AFLC/AFSC  activity  to  develop 
ECS  documentation  tools  is  the  recommended  approach  to  assure  that  the  tool  meets  the 
requirements  of  both  development  and  support. 

Recommended  activities  to  make  software  documentation  less  personpower  intensive 
include  the  following: 

•  Determine  the  minimum  set  of  documentation  required  by  AFLC  for 
ECS  weapon  software  support, 

•  Determine  an  AFLC  format  for  such  documentation, 

•  Negotiate  a  standard  format  and  content  with  AFSC  for  weapon  system 
documentation, 

•  Encourage  and  aid  AFSC  in  developing  a  standard  automated  software 
documentation  system,  and 

•  Use  the  AFSC  documentation  system  for  software  support. 

4. 1.3. 2  ECS  Analysis  Tools 

A  wide  variety  of  ECS  analysis  tools  are  needed  to  support  the  totality  of  ECS  systems. 
Historically,  software  analysis  support  has  been  provided  by  tools  such  as  scientific  simulations, 
interpretive  computer  simulations,  diagnostic  emulations,  static  test  stands  and  ISF’s.  It  is  antic¬ 
ipated  that  in  the  future,  systems  engineering  analysis  support  to  weapon  system  ECS  will  be 
provided  by  modular  extendable  IS^’s.  However,  the  technology  of  microprocessor-based 
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diagnostic  emulators  should  be  encouraged.  Emulators  provide  a  means  of  analysis,  develop¬ 
ment,  and  test  of  operational  ECS  software  when  the  operational  ECS  is  unavailable  to  the  sup¬ 
port  systems  because  of  operational  priorities  or  cost.  Microprocessor-based  diagnostic 
emulators  for  ECS  are  anticipated  to  soon  be  available  at  a  cost  of  10  to  50  thousand  dollars. 

4. 1.3. 3  Specification  Tools 

An  ECS  requirements  specification  language  is  potentially  of  benefit  to  AFLC  for  ECS  sup¬ 
port.  Such  a  tool  could  be  of  even  greater  benefit  to  AFSC.  It  is  therefore  not  recommended  that 
AFLC  independently  develop  a  specification  tool,  out  instead,  support  AFSC  in  such  a  develop¬ 
ment.  The  tool  could  then  be  beneficially  used  by  AFLC  in  maintenance  of  requirements 
specifications  after  PMRT. 

4. 1.3. 4  ECS  Software  De\elopment  and  Test  Tools 

The  tools  addressed  in  this  section  are  those  that  aid  in  ECS  software  source  and  object 
code  development,  in  static  test  (as  opposed  to  dynamic  execution  test)  of  the  code,  and  static 
test  of  the  software  data  communications  and  data  values.  It  is  recommended  that  AFLC  sup¬ 
port  the  development  of  a  set  of  standard  higher  order  language  based  software  tools  for  MIL- 
STD  target  computer  instruction  set  architectures.  A  good  starting  point  would  be  the  develop¬ 
ment  of  J-73  based  tools  targeted  for  M1L-STD-1750  ISA  computer.  Specific  recommended 
AFLC  actions  are  as  follows: 

•  Encourage  upgrade  of  ISA  standards  for  compatibility  with  computer 
interface  standards  (such  as  MIL-STD-1553); 

•  Define  a  minimum  list  of  software  development  tools  needed; 

•  Determine  the  higher  order  language  and  target  computer  ISA  to  be  sup¬ 
ported  by  these  tools  in  coordination  with  AFSC; 

•  Determine  the  hosting  approach  by  designing  for  hosting  on  a  standard 
ISA  or  designing  for  easy  rehosting  on  general  purpose  computers; 

•  Solicit  support  from  other  USAF/DOD  organizations  for  a  cooperative 
tool  development  program;  and 

•  Perform  requirements  analysis,  design,  code,  and  test  of  the  develop¬ 
ment  system. 

4.1.4  Software  Support  System  for  Ada 

The  U.S.  Department  of  Defense  effort  to  design  a  modern  high  order  programming 
language  and  its  support  environment  (system)  for  use  in  embedded  computer  systems  will  be 
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completed  in  the  mid-1980’s.  This  language  and  its  programming  support  environment  had  the 
following  four  original  goals. 

•  Address  the  problem  of  life-cycle  program  costs 

•  Improve  program  reliability 

•  Promote  the  development  of  portable  software 

•  Promote  the  development  of  portable  software  tools 

In  this  section,  some  of  the  main  goals  of  the  Ada  environment  are  presented.  It  is  assumed 
that  a  host/target  development  approach  is  used.  A  host  is  a  computer  with  adequate  storage, 
processing  power  and  peripherals  to  support  software  development  for  the  target  machine. 
Target  and  host  could  be  the  same  machine. 

The  following  are  key  objectives  of  the  Ada  support  environment. 

•  Life  Cycle  Support.  This  objective  implies  adequate  and  comprehensive 
tools,  a  data  base  containing  all  relevant  information,  and  a  configura¬ 
tion  management  system. 

•  Configuration  Control.  This  objective  requires  recording  and  analysis  of 
the  way  in  which  program  versions  (object  code)  were  created  (what 
source  code,  what  tool  versions)  and  used  (test  case  histories,  documen¬ 
tation  version,  etc.). 

•  Tool  Portability.  This  objective  relates  to  ability  to  move  tools  from  one 
support  system  to  another. 

•  Hosting  Portability.  This  objective  is  to  allow  for  easy  rehosting  of  the 
support  environment. 

•  Targeting  Portability.  This  objective  requires  that  the  support  environ¬ 
ment  be  designed  for  easy  retargeting. 

•  Project  Team  Support.  The  Ada  environment  should  be  built  with  pro¬ 
per  tools  to  support  all  members  of  the  software  project  team. 

•  Support  of  the  Ada  Language.  The  support  environment  should  allow 
the  project  team  emphasis  to  be  on  software  development  in  the  full  Ada 
language  rather  than  on  target  machine  software  development. 

•  Open-Ended  Environment.  This  allows  project  team  members  to  develop 
additional  tools  which  are  directly  supportive  of  their  needs. 

•  Host  Requirements.  The  Ada  support  environment  should  be  hostable 
on  a  mid-  to  large-sized  minicomputer. 

These  objectives  are  all  being  addressed  in  the  Ada  environment  now  in  development.  Con¬ 
figuration  control  is  a  central  objective,  and  the  tree  structure  data  base  provides  the  necessary 
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information.  The  Ada  support  environment  appears  impressive  in  its  objectives  and  planned 
content.  The  efficiency  and  cost  effectiveness  of  the  various  support  tools,  which  will  initially  be 
contained  in  the  environment,  is  cm  open  question  which  will  have  to  be  determined  by  user 
experience. 

4.1,5  Acquisition  of  Automated  ECS  Support  Tools 

This  section  discusses  key  AFLC  actions  needed  for  acquisition  of  automated  ECS  software 
tools.  These  tools  are  intended  to  provide  a  standardized,  higher  quality  support  to  the  ECS 
software  practitioner  than  is  currently  available,  thereby  increasing  manpower  productivity. 

The  various  steps  in  this  plan  are  presented  in  the  approximate  order  of  accomplishment, 
although  individual  steps  are  not  completely  interdependent,  and  some  reiteration  may  be 
required.  For  example,  the  number  of  locations  employing  a  given  tool,  the  data  exchange 
requirements  between  various  tools,  the  tool  hosting  concept,  and  the  degree  of  tool  standar¬ 
dization  are  all  interrelated.  Similarly,  decisions  on  network  capability,  or  an  extendable  1SF 
implementation  may  have  a  profound  effect  on  ECS  software  support  tool  requirements. 

Action  1 .  Review  of  ECS  Software  Support  Processes 

Certain  of  the  proposed  ECS  software  support  tools  are  directly  supportive  of  individual 
ECS  support  processes  (e.g.,  documentation,  configuration  management,  change  distribution, 
etc.).  The  procedures  for  implementation  of  support  process  requirements  are  designed  to  allow 
manual  support.  Therefore,  automation  of  current  procedures  may  not  yield  optimum  support. 
New  support  procedures  should  be  considered  which  are  consistent  with  basic  support  require¬ 
ments,  and  which  allow  more  efficient  automation  of  the  process.  The  definition  of  new  concep¬ 
tual  support  procedures  will  require  considerable  effort  and  interaction  with  support  practi¬ 
tioners. 

Ac; ;  nine  Tool  Hosting  Concept 

:  Section  4.1.1,  ECS  support  tools  could  be  designed  to  be  rehosted  to  each 
iocaUv  c-m outer,  hosted  in  a  central  computer  system  with  inter-ALC  network  access, 

or  perhaps  nosted  on  a  standard  computer  with  local  network  access.  The  best  hosting  method 
may  vary  depending  on  the  purpose  of  the  individual  software  tool. 

Determination  of  the  hosting  concept  for  the  various  tools  is  an  important  activity  which 
could  have  significant  financial  consequences.  A  thorough  understanding  of  the  cost  and  sup¬ 
port  effectiveness  tradeoffs  for  various  hosting  options  is  needed.  Decisions  on  the  approach  to 
and  schedule  of  network  development  may  alter  the  hosting  tradeoffs.  Decisions  on  the 
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approach  to  extendable  ISF  development  will  also  affect  tool  requirements  and  may  provide  a 
local  network  on  which  to  host  tools  at  each  ALC. 

Action  3.  Evaluate  Level  of  Tool  System  Integration 

A  software  support  tool  system  could  be  built  with  varying  possible  levels  of  tool  intercom¬ 
munication,  For  example,  when  software  source  code  is  updated,  should  the  software  documen¬ 
tation  and  configuration  management  tools  automatically  be  invoked,  or  should  they  be  called 
manually?  What  amount  and  type  of  data  should  the  various  tools  pass  between  each  other? 
Under  what  conditions  and  controls  should  intertool  data  be  passed?  An  organic  or  contracted 
study,  to  determine  the  recommended  method  of  tool  data  communication  and  data  com¬ 
munication  control  is  needed. 

Action  4,  Evaluate  Level  of  Tool  Standardization 

While  standardization  of  ECS  support  processes  and  support  tools  is  a  goal,  there  will  be 
unique  and  possibly  conflicting  requirements  on  some  projects  which  will  necessitate  departures 
from  standardization.  Further,  the  tool  hosting  concept  has  considerable  effect  on  standardiza¬ 
tion,  since  rehosting  a  tool  on  many  different  local  project  computers  with  different  instruction 
set  architectures  will  tend  to  cause  the  tool  to  have  many  versions.  In  any  case,  a  study  of  the 
costs  and  benefits  of  standardization  is  indicated. 

Action  5.  Determine  DBMS  Conceptual  Requirements 

This  organic  or  contracted  activity  would  establish  a  conceptual  approach  for  adequately 
storing,  accessing  and  maintaining  ECS  informational  support  data.  This  activity  must  considei 
the  types,  location  and  hosting  method  of  the  various  ECS  support  tools,  and  mav  cause  reitera¬ 
tion  of  the  standardization  goals.  The  end  result  of  the  study  is  a  conceptual  data  base  scheme 
and  a  conceptual  information  management  system. 

Action  6.  Determine  Support  Tool  Security  Requirements 

Certain  of  the  data  associated  with  the  various  software  support  tools  will  be  sensitive. 
Financial  data  associated  with  the  various  projects  must  be  safeguarded.  Many  of  the  ECS  soft¬ 
ware  programs  and  test  results  will  be  classified.  The  security  of  this  data  within  its  storage 
media  will  have  to  be  safeguarded.  Both  hardware  and  software  systems  needed  to  safeguard 
this  data  need  to  be  developed,  and  will  affect  the  software  support  tool  cost  and  schedule.  It  is 
necessary  that  the  approach  consider  both  sensitive  and  classified  data,  and  be  consistent  with 
established  regulations.  AFLC  must  establish  the  policy  and  procedures  to  be  used  for 
automated  support  tool  data  security  with  sufficient  clarity  to  allow  identification  of  necessary 
equipment  and  interfaces. 


Action  7.  Define  Tool  Maintenance  and  Management 


While  this  requirements  step  is  administrative  in  nature,  it  is  important  for  AFLC  to  clearly 
establish  the  OPR  for  support  of  automated  ECS  tools.  All  tool  sets,  no  matter  how  well 
designed,  will  require  maintenance  to  correct  deficiencies  discovered  during  operations.  Addi¬ 
tionally,  changing  operational  requirements  wi'l  produce  requirements  for  tool  change. 

Action  8.  Determine  Support  Tr ol  Capabilities 

At  this  point,  the  software  support  processes  considered  for  automation  and  the  planned 
tool  capabilities  need  to  be  reexamined  considering  decisions  made  on  tool  hosting  standardiza¬ 
tion  and  security.  This  organic  activity  should  lead  to  a  target  list  of  tools  anu  tool  capabilities 
for  the  initial  configuration  of  the  automated  ECS  support  system. 

Action  9.  Determine  Needed  Tool  Fragment  Sets 

This  experimental  program  would  probably  be  contracted  by  AFLC.  Its  goal  would  be  to 
identify  the  useful  sets  of  multiuse  tool  fragments  and  to  determine  the  extent  to  which  they  can 
support  tight  integration  of  the  desired  tool  capabilities.  This  program  would  be  performed  by 
identification  of  a  reasonable  set  of  tool  fragments  to  meet  the  needs  of  the  set  of  specific, 
sharply  defined  software  activities  which  are  intended  to  be  supported  by  automated  tools. 

AcMon  10.  Study  Automated  Tool  System  DBMS  Requirements 

This  contracted  activity  would  begin  with  development  of  precise,  detailed  models  of  the 
various  software  activities  to  be  supported.  From  these  models,  the  data  communication 
between  the  user,  the  tool  and  the  tool  fragments  would  be  identified.  From  these  data  handling 
requirements,  the  DBMS  requirements  could  be  identified . 

Action  11.  Contract  for  Support  System 

In  this  activity,  AFLC  will  contract  for  development  of  the  system  of  AFLC  software  tools. 
Contract  management  will  be  by  normal  procurement  rules. 

4.2  MODULAR  EXTENDABLE  INTEGRATED  SUPPORT  FACILITIES 

4.2.1  Requirements 

The  use  of  embedded  computers  in  weapon  systems  is  a  trend  which  is  expected  to  continue 
to  expand  in  the  late  1980’s  and  early  1990’s.  By  1990  all  weapon  systems  will  use  some  form  of 
computer  control  or  digital  data  display.  This  ever-expanding  use  of  computer  controlled 
weapon  systems  generates  new  requirements  for  capable  and  responsive  support  systems.  When 
ECS  systems  were  introduced  in  the  early  1970’s,  each  system  was  supported  in  a  dedicated 
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facility  such  as  the  F-lll  Avionics  Integration  Support  Facility.  With  the  introduction  of 
embedded  computers,  into  new  or  improved  weapon  systems,  the  practice  of  building  dedicated 
support  facilities  for  each  new  system,  or  rebuilding  an  existing  AISF  to  accommodate  improved 
or  new  avionics  systems  generates  unacceptable  ECS  support  costs.  Although  this  practice  is  ex¬ 
pected  to  continue  for  selected  major  aircraft  and  missile  systems,  one  method  of  reducing  these 
support  costs  is  to  build  multiuse  and  expandable  integrated  support  facilities.  This  section 
describes  a  conceptual  multiuse  ISF. 

This  concept  is  based  on  microprocessor  technology  which  will  be  available  in  the 
mid-1980’s,  with  evolutionary  growth  potential  to  meet  the  support  demands  of  the  1990’s. 
Additionally,  this  design  concept  recognizes  the  real  world  requirements  facing  todays  ECS  sup¬ 
port  planners  as  well  as  the  future  use  of  standard  buses  (M1L-STD-15538),  instruction  set 
architectures  (M1L-STD-1750A  and  1862),  and  high  order  languages  (M1L-STD-1589B  and 
Ada).  In  real  world  terms,  existing  ECS  support  tools  and  facilities  must  be  incorporated  into 
the  design  of  new  support  systems,  and  at  the  same  time  allow  it  to  satisfy  the  demands  of  the 
1990’s. 

In  addition  to  accommodating  future  support  requirements,  new  support  facilities  should 
encourage  the  development  "f  a  standard  support  system  equipped  with  common  components 
and  tools.  New  designs  should  also  recognize  that  current  in-place  embedded  computer  systems 
do  not  have  standard  buses,  instruction  sets,  or  standard  high  order  language  support.  ECS  sup¬ 
port  systems  developed  in  the  1980’s  must  incorporate  life  cycle  cost  reduction  features,  satisfy¬ 
ing  today’s  nonhomogeneous  support  needs  and  be  reconfigurable  as  weapon  systems  are  added 
to  or  retired  from  the  active  inventory. 

4. 2. 1.1  Objectives 

An  Integration  Support  Facility  (ISF)  is  defined  in  AFLCR  800-21  as  an  “Applied 
Engineering  Laboratory  designed  to  support  digital  airborne  or  spaceborne  systems  and  sub¬ 
system  associated  programs  and  equipments.”  Avionics  Integration  Support  Facility  (AISF)  is 
used  as  a  generic  term  for  most  ISF’s.  This  concept  is  applicable  to  a  broader  category  of  ECS 
systems,  including  airborne,  spaceborne  and  ground  electronic  systems.  Therefore,  the  term 
Extendable  Integration  Support  Facility  (EISF)  is  used  to  denote  the  broader  applications.  In 
general,  the  integration  support  facility  has  a  twofold  purpose;  it  provides  system  engineers  the 
means  for  hardware/software  integration  and  testing  and  it  also  provides  the  tools  needed  by 
software  engineers  to  modify,  test,  and  validate  ECS  computer  programs.  The  extendable  ISF 
concept  encompasses  both  of  these  requirements,  and  supports  the  structured  environment 
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described  in  the  preceding  section.  The  primary  goal  of  the  E1SF  concept  is  to  reduce  life  cycle 
costs  while  increasing  operator  efficiency,  resulting  in  increased  productivity  and  mission 
responsiveness. 

The  use  of  common  building  blocks  for  ECS  support  facilities  will  reduce  the  proliferation 
of  different  terminals,  operating  systems,  languages,  etc  within  a  facility.  With  a  common 
group  of  hardware  and  software  to  maintain,  support  system  life-cycle  cost  will  be  reduced. 
Operator  efficiency  will  increase  as  the  E1SF  staff  will  be  working  with  a  common  set  of  tools, 
familiar  operating  systems,  and  terminals  with  standardized  keyboards  and  displays.  When  indi¬ 
viduals  are  transferred  from  one  project  to  the  next,  it  often  takes  six  months  to  unlearn  one 
system  and  relearn  another.  Standards  are  often  viewed  as  constraining,  but  when  they  are 
applied  at  the  building  block  level,  they  can  provide  the  designer  with  a  familiar  media.  Imagine 
the  cost  of  aircraft  if  each  part  must  be  custom  made  and  assembled,  or  public  utilities  net¬ 
works,  all  operating  at  different  voltages  and  frequencies.  The  EISF  building  blocks  will  allow 
the  builder  to  rapidly  expand  and  existing  ISF  or  to  create  a  unique  design  for  a  specific  weapon 
system.  This  flexibility  is  consistent  with  the  1990  support  objectives. 

The  extendable  ISF  support  system  will  satisfy  the  following  objectives  discussed  in  Section 

1. 

•  Acquire  and  maintain  a  flexible,  technical  support  base  .  .  . 

•  Provide  efficient  and  effective  life  cycle  management  .  .  . 

•  Acquire  and  maintain  quality  ECS  and  ECS  support  systems  .  .  . 

•  Minimize  critical  organic  ECS  engineering,  scientific  and  technical 
needs  .  .  . 

•  Influence  the  control  of  ECS  and  ECS  Suport  System  proliferation  .  .  . 

.*  This  concept  in  part  supports  these  additional  objectives: 

•  Acquire  and  maintain  ECS  technology  and  intelligence  bases  .  .  . 

•  Accomplish  efficient  and  effective  ECS  support  cost  estimating,  track¬ 
ing,  and  accounting  .  .  . 


4. 2. 1.2  EISF  Development  Philosor 


To  build  a  mature  and  robust  support  system  by  1990,  EISF  designers  should  concentrate 
on  the  capabilities  and  technologies  available  within  the  next  five  years  and  capitalize  on  the 
economics  inherent  in  standardization.  Where  possible,  all  support  systems  should  be  selected 
from  off-the-shelf  commercial  components  to  reduce  the  development  time,  keep  costs  down 
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and  to  ensure  a  mature  im  trial  support  base.  Single  source  components  without  a  proven 
track  record  should  be  avoided.  Highly  advanced  unproven  technology  should  not  be  used  in 
weapon  system  support  systems.  Support  system  designers  should  focus  on  standardization  and 
ease  of  operating  to  increase  reliability,  flexibility,  and  maintainability  and  to  reduce  overall 
support  costs.  The  Extendable  1SF  described  in  the  following  paragraphs  incorporates  these 
goals.  An  Extendable  ISF  must 

•  Support  multiple  systems  with  a  single  integrated  support  facility,  includ¬ 
ing  tnulti-ECS  weapon  systems; 

•  Support  multiple  functions  with  common  modules; 

•  Support  harmonious  interconnection  of  systems  with  dissimilar  architec¬ 
tures,  languages,  program  structures,  and  input/output  requirements; 

•  Support  extension  and  reconfiguration  as  the  number  of  systems  within 
the  support  family  are  increased  or  reduced; 

•  Support  combat  mission  readiness  objectives; 

•  Support  weapon  system  growth  and  planned  product  improvements; 

•  Sustain  life  cycle  management  and  systems  engineering  cost  objectives, 
especially  for  multi-ECS  systems; 

•  Incorporate  in-place  ECS  support  assets  in  the  overall  design;  and 

•  Meet  physical,  processor,  communications,  information,  electrical,  and 
personnel  security  requirements. 

4.2.2  Major  EISF  Elements  and  Design  Alternatives 

Integration  support  facility  design  requirements  are  diverse,  as  they  spread  across  at  least 
three  ECS  categories  (OF?,  EW,  C-E)  and  multiple  weapon  systems,  both  in  the  air  and  on  the 
ground.  To  satisfy  the  needs  of  such  a  wide  range  of  weapon  systems  and  the  requirements  and 
objectives  presented  earlier,  the  Extendable  ISF  must  be  flexible,  have  the  computing  power  of 
large  scale  processors,  and  remain  affordable.  The  ECS  Technology  Forecast,  Volume  VIII  of 
the  baseline  Phase  II  report,  suggests  some  possible  solutions  to  the  problem  of  flexibility  and 
computing  power.  The  envisioned  Extendable  ISF  incorporates  the  following  early  1980* 
technology. 

•  VLSI  and  fiber  optics 

•  Computer  nets 

•  Standard,  high  order  languages 

•  Emulation/simulation 


In  *  next  five  years,  VLSI  will  have  a  major  impact  on  computer  design  and  computer 
communication.  One  of  the  most  influential  future  developments  will  be  a  very  compact  com¬ 
puting  system  (CCS).  The  CCS  will  be  the  same  and  have  the  features  of  today’s  intelligent 
terminal,  with  the  computing  power  of  a  minicomputer,  and  cost  only  a  few  thousand  dollars. 
These  computing  terminals  will  be  capable  of  supporting  several  independent  streams  of  data 
and  control  f  actions  at  the  same  time.  With  the  proper  physical  interconnections  and  network 
control  programs,  CCS  terminals  can  provide  the  flexible  computing  power  required  by  the 
Extendable  ISF. 

The  major  subsystems  and  individual  modules  and  their  global  relationship  are  shown  in 
Figure  4-1.  The  applications  subsystem  includes  the  work  stations  modules,  network  interfaces, 
and  associated  software.  The  direct  support  subsystem  includes  the  target  system  modules  and 
the  associated  simulation/emulation  software,  and  data  collection  and  analysis  software  for 
specific  applications.  The  shared  subsystem  includes  those  modules  shared  with  other  EISF’s  or 
with  work  stations  within  the  EISF. 

The  following  paragraphs  describe  the  applications  subsystem,  the  shared  subsystem,  and 
dir^t  support  subsystem.  Network  system  requirements,  common  to  all  subsystems,  are  covered 
in  paragraph  4. 2. 2. 4. 

4.2.2. 1  Application..  Subsystem/Software 

The  applications  subsystem  includes  both  the  compact  computing  work  station  modules 
and  the  network  communications  and  control  devices.  The  components  and  their  projected 
characteristics  are  presented  in  Tablf  4-3  which  lists  the  hardware  components  and 
characteristics  and  Table  4-4  which  lists  the  general  software  capabilities  needed. 

Specific  software  development  and  support  tools  are  covered  in  Section  4.1;  however,  the 
expected  widespread  use  of  Ada  in  embedded  computer  systems  in  the  1 990’s  must  be  recognized 
and  planned  for.  Individual  EISF’s  should  have  a  complete  Ada  Programming  Support 
Environment  (APSE)  to  provide  the  required  interfaces  and  programming  tools.  A  typical 
APSE  environment  is  shown  in  Figure  4-2. 


4. 2. 2. 2  Shared  Subsystem  and  Software 

The  shared  subsystem  includes  distributed  data  base  management  systems,  file  servers, 
intercenter  network  gateways,  long  term  data  storage  units,  and  peripheral  devices,  such  as  line 
printers,  paper  tape  readers,  character  printers,  programmable  read  only  memory  systems,  etc. 
The  shared  systems  central  to  this  concept  are  the  data  base  machines  and  file  servers.  The  net¬ 
work  gateway  is  an  optional  device  and  will  be  developed  as  an  ECS  Network  component.  The 


Table  4-3.  Typical  Applications  Hardware"' 

Work  Station  Terminal 

•  CPU:  32  bit,  256K  memory,  64K  I/O  buffer,  10  MHz 
clock,  MIL- STD-  1862  prefer  red 

•  Display:  Min  80  column,  32  lines,  128  programmable 
character  set,  9x7  matrix  in  11x9  field,  line 
graphics,  optional  color  graphics 

•  Keyboard:  Typewriter  style  with  numeric  key  pad, 
editing  and  special  function  keys,  programmable 
keys 

Memory  Module 

•  Memory:  Expendable  from  1  to  16  megabytes  in 
64  blocks 

•  Features:  Provisions  for  bubble  memory  cards 
Floppy  Disk  Module 

•  Disks:  8  inch  double  sided,  double  density  floppy 
and/or  8-inch  Winchester  disk 

Network  Interconnect  Module 

•  Media:  Optical  fiber,  double  link,  bi-directional 

•  Characteristics:  Wideband,  1  to  10  megabytes  per 
second 

•  Topology:  Ring,  star  or  combination 

•  Message  Format:  Fixed  priority,  data  packets 

Some  of  these  work  station  modules  are  shown  in  Figure  4-1. 
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Table  4-4.  Typical  Applications  Software 


Operating  System 

•  Kernel:  Real  time  process  and  communications 
management 

System:  task,  file,  device,  and  memory  management, 
including  OS  subroutines 

•  Security:  Access  control,  passwords,  including 
accounting 

Development  Tools 

•  Executive:  Utility  routines,  command  files,  graphics 
invocation,  display  format 

•  Editor:  Text  entry,  character  modification,  strings 
search  substitution,  etc. 

•  Debugger:  Breakpoints,  single  step,  memory/register 
examination,  assembler /disas  sembler ,  etc. 

•  Languages:  FORTRAN,  JOVIAL/J73,  Ada,  cross- 
assemblers,  etc. 

•  Linker:  Object  module  linking,  overlay  utilises,  etc. 

Network  Communications 

•  Protocol:  Appropriate  to  design 

•  Fault  Detect /Recovery:  Self-test  and  dynamic  recon¬ 
figuration  control 
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sharing  of  peripherals  is  not  a  new  concept  and  can  be  easily  implemented  with  simple  switch 
networks,  therefore,  this  section  will  focus  on  data  management  concepts. 

The  use  of  a  data  base  machine  (DBM)  frees  the  work  station  CPU  for  performing  the  data 
base  management  system  functions  and  provides  multiple  work  stations  to  access  a  common 
data  base.  The  data  base  machine  is  a  specialized  processor  with  dedicated  software  which  does 
all  :he  data  base  functions  such  as  storage,  retrieval,  search  and  compare,  and  reports  and 
results.  Commands  and/or  data  are  routed  over  the  network  to  the  DBM,  and  when  the  data 
base  functions  are  complete,  the  DBM  answers  or  responds  with  the  data.  AH  communications 
are  from  commputer  to  computer  over  the  high  speed  network.  Where  data  base  functions  are 
not  required  and  only  file  creation,  storage,  and  retrieval  are  required,  a  file  server  is  used.  This 
function  is  similar  to  having  a  mass  storage  unit  hooked  directly  to  the  work  station;  however, 
the  file  server  allows  all  network  users  access  to  the  files,  if  they  satisfy  the  security  and  access 
controls.  It  is  also  possible  to  make  the  files  available  to  the  direct  support  subsystem  via  the  net¬ 
work.  If  the  network  encompasses  more  than  one  EISF,  then  multiple  EISF’s  can  use  a  single 
DBM/file  server.  When  connected  through  a  network  gateway,  the  DBM  can  serve 
geographically-distributed  users.  This  feature  will  be  vital  to  the  configuration  management  of 
systems  used  on  multiple  aircraft  or  ground  based  weapon  systems,  JTIDS,  IFF,  comrn  systems, 
etc.  Table  4-5  lists  the  features  and  characteristics  of  the  EISF  DBM  and  file  server.  Table  4-6 
presents  a  list  of  peripheral  devices  which  could  be  shared  by  EISF’s  or  compact  computing 
work  stations. 

4.2. 2. 3  Direct  Support  Subsystem  and  Software 

The  direct  support  subsystem  modules  include  both  laboratory  and  weapon  systems 
resources  needed  to  analyze,  modify,  and  test  ECS  software.  These  subsystems  have  been  given 
a  variety  of  names;  software  test  stands,  software  work  benches,  hot  bench/test  stands,  etc.  The 
complexity  and  capability  of  these  test  stands  depends  on  the  specific  applications  and  ranges 
from  a  stand-alone  commercial  development  system  to  complete  one-of-a-kind  dynamic  simula¬ 
tion  systems  with  operator  consoles  and  cockpit  to  provide  interactive  man  and  machine 
inputs/outputs.  Implementation  of  various  applications  is  shown  in  Figures  4-3  and  4-4.  These 
devices  provide  the  tools  neede,  ■ 

•  Analyze  proposed  changes  to  the  ECS  software, 

•  Develop  proposed  changes  to  the  ECS  baseline, 

•  Test  the  changes  prior  to  implementation  in  the  baseline, 

•  Analyze  the  results  of  testing, 


Data  Base  Machine 


•  CPU:  Application  dependent,  single  or  multiple  pro¬ 
cessor  design  depends  on  specific  DBMS  requirements 

•  Mass  Storage:  Multiple  disk  systems,  both  fixed  and 
removable 

•  Interface:  High  level,  complete  transaction  trans¬ 
mitted,  supports  multiple  machine  access. 

•  Security:  Multilevel  access  control  for  both  classified 
and  unclassified  data 

File  Server 

•  CPU:  Work  station  module  dedicated  to  file  service 
applications 

•  Mass  Storage:  Multiple  disk  system,  both  fixed  and 
removable 

•  Interface:  Low  level,  create,  fetch,  store 

•  Security:  Multilevel  access  control  for  both  classified 
and  unclassified  files 


Table  4-6.  Shared  Hardware  (Peripherals) 


Printer  s 

•  Character 

•  Line 

•  High  speed 

•  Letter  quality 

•  Color 

Plotters 

•  Graphic 

•  Flatbed 

•  Drum 

Tape  Drives 

•  7/9  track 

•  Cartridge 

Paper  Tape  Devices 

•  Punch 

•  Reader 

Miscellaneous 

•  PROM  programmers 

•  Digitizers 
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Figure  4-4.  Example  Integration  Test  Bed  Architectures 


•  Verify  ECS  performance  after  the  baseline  has  been  changed,  and 

•  Test  system  avionics  in  a  controlled  environment. 


4. 2. 2. 3.1  E1SF  Primary  Support  Tools.  In  the  Extendable  ISF  the  primary  ECS  support  tools 
are  system  hot  benches,  emulators,  simulators,  and  computer  monitoring  devices.  In  most  cases, 
system  hot  benches  are  unique  to  the  individual  ECS  application,  whereas,  the 
simulator/emulators/monitcrs  are  more  general  purpose  tools.  The  following  is  a  list  of  some  of 
the  general  purpose  tools  required  by  the  E1SF. 

•  Interpretive  Computer  Simulation  (ICS).  The  ICS  is  bit-for-bit  simula¬ 
tion  of  the  target  computer  via  software  and  a  general  purpose  computer. 

It  allows  test  and  diagnostic  analysis  of  the  actual  operational  program, 
however  most  are  very  slow  and  do  not  run  in  real  time. 

•  Diagnostic  Emulation  (PE).  The  DE  performs  functions  similar  to  the 
ICS  but  its  run  time  is  much  faster.  Microcoded  instructions  provide  the 
capability  for  real  or  near  real  time  operation. 

•  Hardware  Simulation  Kernels  (HSK).  HSK's  are  used  to  simulate/stimu¬ 
late  inputs  to  the  target  system  and  process  outputs  to  calculate  future 
input  stimuli. 

•  Programmable  Interface  Units  (P1U).  PIU’s  are  used  to  interface  dissim¬ 
ilar  buses  to  the  HSK’s  and  to  computer  monitor  and  control  devices. 

•  Computer  Monitor  and  Control  Devices  (CMAC).  CMAC’s  are  used  to 
observe  and  record  target  computer  operation  on  a  hot  bench. 

Special  purpose  hot  benches  or  software  test  stands  normally  are  unique  to  the  application. 
However,  they  have  general  requirements  to  demonstrate  functional  performance  of  the  ECS 
software  on  the  actual  test  weapon  system  computer,  and  to  provide  reai  time  simulation  of  the 
weapon  system  computer  environment  to  include  generation  of  input  signals,  plus  evaluation 
and  interpretation  of  output  signals.  Recommended  EISF  hot  bench  configurations  are 
presented  in  Figures  4-5  and  4-6.  Figure  4-5  is  a  software  test  bench  and  Figure  4-6  is  an  integra¬ 
tion  test  bench.  Other  configurations  which  emphasize  diagnostic  capabilities  can  be  constructed 
from  the  basic  EISF  building  blocks  are  shown  in  Figure  4-7. 

4.2. 2. 3. 2  Programmable  Interface  Units  (P1U).  Programmable  interface  units  will  allow  the 
interconnection  of  a  wide  variety  of  nonstandard  computer  buses  to  the  EISF  network.  In  turn, 
the  standard  network  interfaces  allow  all  the  devices  on  the  network  to  interact  with  the  target 
computers.  To  enhance  standardization,  the  PIU’s  should  be  built  from  commercially  available 
single-board  computers  which  have  a  mature  industrial  support  base  and  are  part  of  an 
upwardly  compatible  family  of  microprocessors.  Examples  include  Intel’s  Multibus,  Motorola’s 
Versabus,  or  similar  single  board  computer  systems. 
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Figure  4-5.  Software  Test  Benct 
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Figure  4-7.  Diagnostic  Capability  Hot  Bench  Alternatives 


The  PIU  is  designed  with  sufficient  logic  to  mask  the  distinguishing  characteristic  of  one 
system  bus  from  another,  without  restricting  the  data  flow.  By  using  a  built-in  microprocessor 
to  control  all  interface  and  formatting  functions,  the  host  and  target  computers  are  unburdened 
from  interface  tasks.  A  block  diagram  of  a  typical  microprocessor-controlled  formatter  or  inter¬ 
face  unit  is  shown  in  Figure  4-8.  The  use  of  these  standard  PIU  modules  will  significantly  reduce 
the  need  for  costly  dedicated  interfaces.  More  advanced  designs  will  use  dedicated  single  chip 
VLSI  and  VHSIC  computers  with  onboard  memory  for  this  interface  function.  The  onboard 
memory  can  be  mask  programmed  to  convert  any  of  the  standard  data  exchange  protocols  to  a 
wide  variety  of  internal  bus  structures  or  network  interconnect  standards.  To  change  the  proto¬ 
cols  serviced  by  any  one  PIU  would  only  require  the  removal  of  the  preprogrammed 
microprocessor  and  replacement  with  an  appropriate  coded  one.  Electrical  compatibility  could 
be  maintained  with  jumpers  or  dipswitches.  The  PIU’s,  whether  on  a  PC  card  or  integrated  cir¬ 
cuit,  should  be  compatible  with  the  I/O  requirements  of  the  network  interface,  the  computer 
monitor  control  device,  the  hardware  simulators,  and  the  environmental  stimulations.  To  maxi¬ 
mize  standardization,  a  standard  PC  card  to  target  systems  interface  should  be  used,  enabling 
the  PIU  to  support  a  wide  variety  of  interface  requirements.  Due  to  the  number  of  different 
systems  in  use  today,  it  may  be  necessary  to  build  PIU’s  for  a  specific  family  of  processor  buses. 
When  military  standard  buses  are  widely  used  in  air,  ground,  and  space  systems,  only  a  small 
number  of  PIU  types  may  be  required.  Figure  4-9  illustrates  how  a  programmable  interface 
could  be  combined  with  a  hardware  simulation  kernel  to  form  a  hardware  simulation  module. 

4. 2. 2. 3. 3  Hardware  Simulation  Kernels  (HSK).  Programmable  hardware  simulator  kernels  are 
dedicated  devices  capable  of  simulating  the  digital,  and  selected  portions  of  the  analog  environ¬ 
ment.  which  surrounds  the  target  system.  Each  simulator  consists  of  a  microprocessor,  A/D  and 
D/A  card,  memory  card,  and  disk  controller,  plus  one  of  the  programmable  irterface  cards 
discussed  in  previous  paragraphs  and  shown  in  Figure  4-8.  By  using  programmable  interface 
cards  with  standard  electrical  connections,  it  will  be  possible  to  use  the  actual  hardware  or  a 
hardware  simulator  on  the  hot  bench.  This  interchangeability  allows  the  hot  bench  to  be  con¬ 
figured  for  integration  testing  or  reconfigured  for  software  development  tasks  requiring  only 
simulated  inputs.  In  cases  where  digital  simulation  is  not  possible,  a  digital  controlled  stimulator 
is  used  to  provide  inputs  to  the  avionics  hardware. 

4. 2. 2. 3. 4  Computer  Monitor  and  Control  Device  (CMAC).  A  CM  AC  device  collects  data  on  the 
internal  operation  of  the  target  computer  when  it  is  running  an  application  program.  The  ability 
to  observe  ECS  operation  without  altering  the  applications  software  or  halting  the  target  com¬ 
puter  makes  the  CMAC  a  powerful  software  maintenar  'e  and  test  tool.  CM  AC’s  can  be  pro¬ 
grammed  to  selectively  collect  target  computer  data.  Typical  data  collection  capabilities  include 
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Programmable  Interface  Unit  (PIU) 


Figure  4-9.  Reprogrammable  Hardware  Simulator 


•  Collect  data  value  based  on  memory  unit, 

•  Collect  data  value  when  it  exceeds  limit  checks, 

•  Collect  data  value  based  on  instruction/memory  road, 

•  Trace  register  operations  based  on  instruction  access, 

•  Trace  nonsequential  program  counter  values,  and 

•  Issue  interrupts  based  on  condition. 

To  date,  CM  AC’s  have  been  custom  designed  to  a  unique,  but  similar  set  of  requirements 
and  for  compatibility  with  particular  target  computers.  Generally  they  are  custom  fabricated 
largely  out  of  discrete  components,  with  little  or  no  use  of  standard  off-the-shelf  microprocessor 
controlled  boards.  Differences  in  CMAC  design  are  driven  by  the  following: 

•  Designer  pereference  or  technology  available  at  design  time, 

•  Target  computer  interface  differences, 

•  ISF  host  computer  interface  differences,  and 

•  Data  collection  capabilities. 

If  a  standard  set  of  CMAC  data  collection  capabilities  were  selected,  a  standard  CMAC 
core  unit  could  be  developed,  based  on  off-the-shelf,  relatively  low  cost  standard  modules.  Only 
the  interfaces  to  the  target  and  host  computers  would  have  to  be  custom  tailored  to  specific 
systems  and  applications.  It  is  estimated  tnat  approximately  Va  of  a  CMAC  could  be  standard¬ 
ized.  Target  and  host  computer  interface  problems  could  be  further  reduced  by  building  target 
computer  family  oriented  interfaces,  e.g.,  DEC  PDP-11,  Data  General  NOVA,  ROLM  1600, 
IBM  4  Pi,  IBM  AP101C,  etc. 

A  block  diagram  of  a  programmable  CMAC  is  shown  in  Figure  4-10.  Data  is  collected 
through  the  programmable  target  computer  interface,  and  stored  in  a  first  in-first  out  buffer 
approximately  4000  words  long.  The  processor  unit  consists  of  a  set  of  processor  boards  pro¬ 
grammed  to  scan  the  input  buffer  for  data  to  be  collected/acted  upon  based  on  CMAC  control 
breakpoints  loaded  by  the  operator  in  the  breakpoint  buffer.  Desired  output  data  is  loaded  by 
the  processor  section  into  the  real  time  buffer,  and  collected  through  the  programmable  target 
computer  interface. 

4. 2. 2.4  Network  Structure 

The  central  feature  of  the  EISF  is  a  network  which  serves  as  the  bridge  between  the  applica¬ 
tions,  support,  and  service  environments.  This  network  will  support  the  interconnection  of  a 
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wide  variety  of  non-homogeneous  computing  systems  and  systems  built  specifically  for  network 
operations.  This  is  a  crucial  EISF  feature  if  it  is  going  to  support  the  multitude  of  existing  ECS 
systems,  as  well  as  new  systems  designed  under  current  military  standards.  Additional  network 
features  include 

fi  Simple  low  cost  standard  access  methcls; 

•  Virtual\'onnection  of  functions; 

a  High  speed  noise  free  data  transfer; 

•  High  reliability  in  laboratory  environment;  and 

•  Security  from  EMI,  TEMPEST,  and  interception. 

Most  of  these  network  features  are  determined  by  the  transportation  medium;  coaxial  cable, 
optical  fibers,  or  twisted  pair.  Table  4-7  compares  the  available  transport  media  against  the 
above  criteria.  It  is  evident  fiber  optics  will  have  payoff  when  connector  costs  are  reduced.  The 
current  trend  is  toward  more  economical  interconnections. 

Currently  available  off-the-shelf  network  designs  have  focused  on  the  use  of  coaxial  cable 
to  interconnect  systems  functions.  Examples  include,  Ethernet,  HYPERchannel,  Net-one, 
Localnet,  etc.  The  principal  advantage  of  coaxial  cable  is  its  superior  cost  effectiveness,  flexibil¬ 
ity,  and  performance  when  compared  with  the  twisted  cable  pairs  currently  in  use.  Initially, 
EISF  networks  may  use  available  coaxial  technology  due  to  cost;  however,  the  focus  in  1985 
through  1990  should  be  on  fiber  optics.  Figure  4-11  projects  that  the  use  of  optical  transport 
medium  will  grow  rapidly  from  1985  to  1990.  The  principal  benefit  of  optical  fibers  are  wide 
bandwidth,  immunity  from  EMI  crosstalk,  and  ground  loops.  These  advantages  result  in  highly 
reliable  low  error  rate,  and  relatively  secure  communications  systems.  The  wide  bandwidth, 
immunity  from  EMI,  lack  of  crosstalk  and  ground  loops  are  definite  assets  in  an  EISF  environ¬ 
ment.  Therefore,  the  EISF  designer  must  weight  the  additional  cost  of  fiber  optics  against  its 
accrued  benefits.  It  should  be  pointed  out,  however,  that  the  EISF  design  is  not  dependent  on 
any  single  transport  medium,  but  can  be  implemented  using  a  variety  of  systems,  combining  all 
three  media  into  a  single  system  if  necessary. 

Another  feature  of  local  networks  which  impacts  on  the  EISF  design  is  the  network 
topology.  Figure  4-12  illustrates  the  four  basic  local  computer  network  topologies  and  points 
out  the  relative  merits  of  each. 


^A  virtual  circuit  is  one  which  appears  to  provide  a  sustained  sequence  of  transmissions  or  a 
logical  channel. 
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Table  4-7.  Network  Transport  Medium 


Base 

Band 

Coax 

Broad 

Band 

Coax 

Fiber 

Optics! 

Wire 

Pair 

Low 

Med 

High 

Low 

Yes 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

Yes 

High 

High 

Medf 

High 

Yes 

Yes 

Yes 

No 

Med 

Med 

High 

Low 

Med 

Med 

High 

Low 

Criteria 

Connection  Cost 
Standard  Access 
Virtual  Connection^ 
Reliability 

High  Speed  (>10  Mbps) 
Noise/EMI  Immunity 
Security 


t Virtual  Circuit,  appears  to  provide  a  circuit  then  a  sustained 
sequence  of  transmissions  on  a  logical  channel. 

^  Tr  end  is  toward  lower  cost  connectors. 

^Connector  reliability  is  increasing. 


TYPE 

ADVANTAGES 

DISADVANTAGES 

POINT  TO  POINT 

STAR 

RING 

SIMPLICITY 

SIMPLICITY 

NO  CENTRAL  NODE, 
SIMPLE 

COSTLY,  LEAST  VERSATILE 

CENTRAL  NODE  FAILURE 
UNDIRECTIONAL,  NODE  FAILURE 

BUS 

NO  CENTRAL  NODE, 
SIMPLE 

UNDIRECTIONAL 

The  choice  of  topology  will  depend  on  the  application,  the  transportation  medium,  and  the 
methods  used  to  distribute  data.  However,  in  E1SF  applications,  the  ring  and  bus  topology  have 
seme  significant  advantages. 

•  Simple  structure 

•  No  central  node 

•  Multiprocessing  supported 

•  Higher  efficiency  and  productivity 

•  Easily  expanded 

The  ring  and  bus  configurations  avoid  the  problems  and  inefficiencies  associated  with  central 
processing.  Centralized  architectures,  such  as  the  star  configuration,  require  every  bit  of  infor¬ 
mation  to  pass  through  the  CPU,  typing  up  the  system  bus  as  well  as  the  processing  power  of  the 
system.  In  a  single  CPU  multitasking  environment  only  one  task  can  have  the  CPU’s  attention 
at  any  one  time.  In  the  generic  EISF  multiprocessor  environment  each  computer  runs 
autonomously  at  its  own  application,  transferring  information  between  functions  only  as 
necessary  keeping  the  network  available  for  priority  use.  Adding  or  subtracting  functions  or 
processes  does  not  significantly  impact  other  functions  on  the  network.  Messages  enter  the  net¬ 
work  and  are  passed  from  node  to  qode  until  it  reaches  its  destination.  There  are  no  routing 
decisions  to  be  made  by  a  central  CPU.  The  only  routing  requirements  are  that  each  node 
recognizes  those  messages  intended  for  it.  This  design  is  not  without  problems.  When  two  or 
more  nodes  attempt  to  enter  messages  onto  the  network  at  the  same  time  they  collide  with  each 
other.  To  prevent  this  from  destroying  the  efficiency  of  the  network,  there  is  a  control 
mechanism. 

The  control  mechanism  used  by  emerging  networks  such  as  Ethernet,  KYPERchannel,  Net  - 
one,  etc.  is  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD).  Under  this 
scheme  a  node  listens  and  if  the  network  is  clear  transmits  its  message  packet.  During  transmis¬ 
sion  each  node  listens  for  a  collision.  If  a  collision  occurs  it  waits  and  tries  again.  The  period 
each  node  waits  is  determined  by  a  probabilistic  algorithm.  This  method  of  determining  who  has 
control  of  the  network  is  highly  efficient,  but  does  not  meet  the  needs  of  an  EISF  network.  The 
EISF  requires  a  virtual  circuit  to  ensure  real  time  processes  can  be  serviced  on  a  predetermined 
schedule  or  priority.  There  are  a  variety  of  deterministic  control  strategies  that  will  support  the 
generic  EISF  design.  The  most  effective  of  these  strategies  are  associated  with  the  ring  topology, 
however,  the  bus  structure  can  also  be  used.  In  general,  these  strategies  are  based  on  a 
mechanical  whereby  control  is  passed  sequentially  around  the  ring  from  node  to  node. 
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•  Daisy  Chain:  Dedicated  wires  pass  control  information  from  node  to 
node. 

•  Control  Token:  Control  information  is  passed  in  a  special  bit  pattern 
over  the  regular  data  channel. 

•  Message  Slots:  Control  is  continuously  transmitted  around  the  network 
in  a  series  of  message  slots  which  are  filled  or  emptied  as  required. 

The  bus  structured  network  is  difficult  to  implement  using  a  deterministic  scheme  without 
making  one  node  the  controlling  node,  which,  in  turn,  detracts  from  the  E1SF  multiprocessing 
environment.  As  stated  earlier,  the  most  commonly  used  bus  control  strategy  is  CSMA/CD 
which  is  not  appropriate  to  this  requirement. 

Protocols  are  also  part  of  the  control  structure.  As  in  the  long  haul  networks  discussed  in 
Section  4.4,  local  network  protocols  are  layered,  proceeding  from  the  most  basic  level  of 
transferring  groups  of  bits  without  knowledge  of  their  meaning,  to  higher  level  applications 
which  use  the  bits  to  communicate  remote  actions.  Local  networks  must  support  a  wide  variety 
of  hosts,  ranging  from  dedicated  microprocessor  to  large  data  base  machines.  To  simplify  com¬ 
munications  processing,  larger  headers  can  be  used.  For  example,  headers  with  fixed  fields,  in 
fixed  locations;  and  address  which  translates  directly  to  queues,  buffers,  ports,  or  processes 
without  consulting  look  up  tables  can  simplify  data  handling. 

Another  feature  of  local  networks  supporting  low  level  protocols  is  the  inherent  short 
transmission  delay.  Low  transmission  delays  can  eliminate  the  need  for  complex  buffers,  flow 
control,  and  network  congestion  mechanisms.  However,  there  are  other  data  rate  considera¬ 
tions.  While  the  data  rate  can  make  exchanges  essentially  instantaneous,  its  speed  cannot 
eliminate  the  problem  of  two  systems  on  the  network  communicating  at  different  rates. 
Therefore,  it  is  still  necessary  to  design  protocols  with  sufficient  generality  to  cope  with  com¬ 
munication  disparities.  Such  disparities  include 

•  Data  rate  mismatch, 

•  Receipt  and  acknowledge  delay  mismatch,  and 

•  Sender/receiver  buffer  length  mismatch. 

Another  aspect  of  the  protocol  which  must  be  discussed  is  its  structure  and  its  compatibility 
with  higher  level  structures.  The  EISF  network  is  projected  to  interface  with  long  haul  networks 
as  well  as  data  base  machines  and  large  scale  hosts.  These  interfaces  require  high  level,  more 
elaborate  protocols,  therefore  the  EISF  needs  a  two-level  protocol.  The  iower  level  provides  the 
basic  functions  of  delivering  an  addressed  message  to  one  or  many  destinations  whereas  the 


higher  level  performs  complete  functions.  These  lower  level  protocols  can  be  implemented 
entirely  in  hardware  in  contrast  to  the  higher  levels  which  must  be  software  implementable.  To 
maintain  the  flexibility  of  the  P1U  a  software  approach  is  recommended  for  both  levels.  A  soft- 
ware  controlled  PUJ  with  both  low  and  high  level  protocols  will  also  enhance  the  decentralized 
computing  capability  of  the  EISF  network.  The  high  level  protocols  can  be  used  to  communicate 
through  long  haul  gateways,  data  base  machines,  and  in  some  cases  shared  memory  and  files. 

Protocol  efficiency  can  be  increased  when  dealing  with  larger,  more  sophisticated  systems 
by  integrating  portions  of  the  networks  file  handling  system  within  the  individual  operating 
systems  on  the  EISF  network.  By  incorporating  the  protocol  and  user  authentication 
mechanisms  in  individual  operating  systems,  the  interchange  of  information  between  the  various 
machines  can  be  accomplished  with  minimum  user  intervention. 

Once  the  individual  EISF’s  are  developed  and  prior  to  implementation  of  the  long  haul  net¬ 
work,  it  is  advisable  to  fully  develop  local  area  networks  encompassing  all  EISF’s  located  on  a 
single  ALC.  These  local  area  networks  would  be  composed  of  a  collection  of  local  network 
(subnetworks)  that  have  been  implemented  with  various  technologies  and  perhaps  different 
transmission  rates,  but  using  identical  software  protocols,  compatible  packet  sizes,  and  a  single 
overall  homogeneous  address  space.  Figure  4-13  is  a  graphic  representation  of  multiple  loop 
interconnected  through  a  common  data  base  machine  which  in  turn  is  interconnected  to  other 
ALC  local  networks  through  long-haul  gateways.  These  long-haul  networks  are  discussed  in 
Section  4.4. 


4. 2. 2. 5  Summary 

This  section  of  the  report  discusses  the  generic  design  of  an  ISF  capable  of  supporting 
multiple  ECS  categories,  multiple  weapon  systems,  and  single  weapon  systems  employing  multi¬ 
ple  ECS  systems.  Appendix  D  presents  a  high  level  view  of  how  the  generic  design  could  be 
applied  to  ground  EW  systems  using  available  technology  and  currently  in-place  assets. 

EISF  development  and  physical  plant  development  are  discussed  in  the  next  section. 
However,  prior  to  reaching  this  phase  in  the  procurement  cycle  there  are  a  number  of  studies 
and  evaluations  which  should  be  conducted  to  further  define  the  specification  for  individual 
components  of  the  EISF. 


These  studies  include 


Work  station  definition  and  selection; 

Network  design  to  include  transport  medium,  topology,  interface,  and 
protocol  (this  is  part  of  the  EISF  Requirements  Definition  Phase); 
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•  Programmable  hardware  simulator  design; 

•  Programmable  computer  monitor  and  control  design;  and 

•  Selection  of  a  stand- alone  data  base  machine. 

Recommended  activities  include 

•  Develop  prototype  local  network  for  EW,  OFP,  and  ATD  using  current 
technology  and  where  possible  available  assets; 

•  Expand  prototype  into  full  scale  E1SF;  and 

•  Interconnect  individual  EISF’s  through  a  data  base  machine. 

4.2.3  E1SF  Development  and  Integration  Considerations 

The  development  of  an  EISF  from  modular  building  blocks  which  will  satisfy  the  needs  of 
multiple  users  supporting  a  wide  variety  of  ground,  air,  and  spaceborne  weapon  systems,  is 
highly  complex  and  requires  extensive  planning.  This  planning  must  extend  throughout  the  life 
cycle  of  the  support  systems  and  must,  address  the  need  for  long  term  budgeting  cycles.  Initially 
the  extended  1SF  must  be  funded  as  a  line  item  with  its  own  PMD.  After  the  program  has 
matured  and  the  major  modules  are  in  the  inventory,  individual  iSF’s  can  be  funded  incre¬ 
mentally  as  part  of  the  weapon  system. 

In  the  past  ECS  support  planning  has  been  generally  inadequate  and  should  be  strength¬ 
ened  in  the  future,  as  the  flexibility  provided  in  this  conecpt  is  not  achievable  unless  all  compon¬ 
ents  are  available  to  the  EISF  builder.  Once  the  modules  are  available,  builders  can  tailor  EISF 
capabilities  to  meet  specific  weapon  system  requirements  without  having  to  go  through  an  exten¬ 
sive  development  cycle.  To  achieve  this  goal  the  overall  EISF  concept  must  have  a  detailed  plan 
and  long  term  financial  support. 

The  planning  and  acquisition  activities  necessary  for  the  procurement  of  EISF  subsystems 
are  summarized  in  Section  5,  paragraph  5.2.2.  In  addition  to  these  activities,  the  development  of 
a  physical  plant  to  house  the  EiSF  must  be  planned  and  coordinated  with  other  Air  Logistic 
Center  support  activities.  Buildings  must  be  prepared  to  accept  the  EISF’s  and  staffs  trained  to 
operate  the  support  systems.  Training  recommendations  are  discussed  in  Section  3.  Facility 
design  and  security  requirements  are  summarized  in  the  following  paragraphs. 

Facility  requirements  are  concerned  with  the  space  and  physical  allocations  necessary  to 
implement  the  EISF.  Prime  considerations  are  floor  space,  power  requirements,  cooling  require¬ 
ments,  and  special  security  requirements. 


To  determine  the  floor  space  requirements,  the  itemized  equipment  must  be  located  on  a 
scaled  floor  plan  in  order  to  help  determine  the  needed  structure.  The  floor  space  should 
consider 

•  Room  for  personnel  expected  to  provide  support  (office  space,  security 
control), 

•  Any  added  requirements  for  power/cooling  equipment, 

•  Hall  and  aisle  ways, 

•  Special  vaults  and  libraries, 

•  Equipment  maintenance  room,  and 

•  Growth. 

To  prevent  premature  technical  obsolescence,  the  planned  facility  should  have  raised 
floors,  relocatable  walls,  open  core  design,  floor-to-floor  chases,  environmental  and  industrial 
standard  electrical  distribution  systems.  Building  flexibility  into  the  initial  design  will  allow  the 
facility  to  be  reconfigured  to  meet  future  requirements. 

The  electrical  power  requirements  for  each  of  the  avionics,  commercial,  and  special  equip¬ 
ment  must  be  considered  together  to  determine  the  total  power  requirements  for  the  facility. 
Sufficient  margin  should  be  provided  for  growth.  Power  requirements  for  avionics  equipment 
generally  require  different  types  of  power  including:  230/400  Vac  400  Hz,  115/200  Vac  400  Hz, 
1 15/200  Vac  60  Hz,  and  28  Vdc.  Conventional  60  Hz  building  power  is  adequate  to  support  area 
requirements  such  as  lighting,  convenience  outlets,  office  equipment,  etc.  This  building  power 
should  be  kept  separate  from  the  equipment  power.  In  some  cases  where  security  is  a  concern, 
filtered  power  may  be  required. 

Avionics  equipment  generally  requires  special  cooling  which  must  be  considered  on  an  item 
by-item  basis.  Various  categories  of  cooling  systems  may  be  required  such  as  liquid,  forced  air, 
and  draw -through  types. 

The  environmental  control  requirements  (lighting,  heating,  ventilation,  and  air  condition¬ 
ing)  must  be  in  accordance  with  AFM  88-15.  The  heat  load  generated  by  the  equipment  can  be 
estimated  from  the  electrical  requirements  of  the  individual  equipment. 

Various  special  requirements  must  be  included  based  on  the  specific  application.  Raised 
floors  can  be  specified  to  facilitate  under-floor,  air  ducts,  power,  grounding,  and  signal  cable 
runs.  A  special  fire  protection  system  may  be  included.  If  an  IMU  test  table  is  included  in  the 
facility,  benchmarks  must  be  provided  with  a  measurement  (to  a  specified  accuracy)  of  latitude, 
longitude,  altitude,  and  direction  of  true  north. 


The  growing  trend  to  include  classified  intelligence  data  in  the  ECS  software  and  the  need 
to  protect  weapon  systems  software  from  sabotage  will  drive  increased  E1SF  security  require¬ 
ments.  The  EISF  concept  incorporates  a  number  of  security  features,  including  the  use  of  multi¬ 
level  file  access  controls,  log-in  control,  fiber  optic  data  transmission,  and  TEMPEST  approved 
peripherals.  Even  with  these  built-in  features  each  facility  housing  an  EISF  must  meet  specific 
DOD  security  standards.  The  following  summarizes  DOD  policies  with  respect  to  ADP  security 
requirements.  (Specific  guidance  is  contained  in  AFR  300-8.) 

•  Each  facility  system  must  obtain  an  initial  written  approval  from  the 
cognizant  government  security  agency  prior  to  processing. 

•  A  closed  area  is  to  be  established  for  each  classified  facility.  To  maintain 
the  integrity  of  the  system,  the  closed  area  controls  are  to  be  maintained 
even  during  those  penods  when  there  is  no  classified  material  in  the 
system. 

•  Classified  material  is  not  to  be  transmitted  to  or  from  a  remote  terminal 
except  by  means  of  approved  methods.  If  ctyptographic  methods  are 
used,  AFKAG-1  procedures  apply. 

•  The  personnel  having  access  to  classified  equipment  are  to  possess  a 
security  clearance  and  need-to-know  for  the  highest  classification  and 
most  restrictive  category  of  classified  material  contained  or  processed  in 
the  system.  If  it  becomes  necessary  for  maintenance  personnel  not 
possessing  such  clearances  to  access  the  system,  they  are  to  be  accom¬ 
plished  by  an  escort,  duly  designated  for  that  purpose. 

•  If  computers  of  computer-like  devices  and  associated  peripheral  equip¬ 
ment  are  used  in  processing,  displaying  or  forwarding  national  security 
or  security-related  information,  then  TEMPEST  controls  must  be 
applied  (1AW  AFR  100-45). 

4.3  ECS  READINESS  SUPPORT 

As  outlined  in  Volume  II  and  further  detailed  in  a  classifit  i  section  of  the  Phase  II  report, 
the  ECS  readiness  support  issue  involves  the  requirement  for  AFLC  to  maintain  Air  Force 
weapon  systems  in  a  combat  ready  condition  through  modifications  to  be  associated  ECS  soft¬ 
ware.  These  modification  requirements  may  come  as  the  result  of:  1)  outdated/inoperative  ECS 
software  at  PMRT  transition;  2)  desire/necessity  to  change  or  increase  the  weapon  systems  ini¬ 
tial  design  capabilities  after  PMRT;  and/or,  3)  respond  to  a  changed  or  new  threat  environment 
in  which  these  systems  must  perform  during  their  operational  life  span.  Of  the  above  listed  three 
reasons,  the  requirement  to  “respond  to  a  changed  or  new  threat  environment”  is  by  far  the 
most  urgent  and  pressing  reouirement.  In  fact,  this  requirement,  in  almost  all  cases,  is  the  basic 
reason  for  all  ECS  readiness  changes. 
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To  fully  appreciate  the  impact  tl  e  readiness  issue  is  having  and  will  continue  to  have  on 
AFLC,  one  must  understand:  1)  the  functions  required  tc  perform  this  apport  task;  2)  the  data, 
tools,  and  resources  necessary;  and  3)  the  responsible  agencies  either  to  ked  or,  by  the  nature  of 
the  job,  required  to  perform  the  various  functions. 

To  better  illustrate  the  problem  while  amp'ifying  on  the  material  contained  in  Volume  II  of 
the  Phase  II  report,  a  st  ictured  methodology  is  used  for  the  analysis.  This  type  approach  allows 
one  to 

•  Think  in  a  structured  way  about  the  readiness  support  issues  and  their 
accompanying  complex  support  problems; 

•  Break  the  total  problem  into  several  lower  and  less  complex  issues 
wherein  analysis  of  support  resources,  equipment,  and.  responsibilities 
may  be  identified;  and 

•  Communicate  the  analysis  and  the  resulting  recommendations  in  clear, 
concise,  and  traceable  fashion. 

Prior  to  discussion  of  the  analysis,  a  short  introduction  into  the  analysis  methodology  is 
appropriate.  The  methodology  to  be  used  is  to  construct,  on  paper,  a  model  of  the  readiness 
support  issue.  The  readiness  issue  is  decomposed  into  its  constituent  parts.  To  accomplish  this 
decomposition,  boxes  are  interconnected  with  arrows.  Starting  with  the  most  general  or  abstract 
description  of  the  issue  represented  in  a  single  box,  decomposition  or  breakdown  of  that  box 
into  a  number  of  more  detailed  boxes  begins.  Each  cf  these  boxes  represents  a  major  function  of 
that  single  “parent”  box. 

In  addition  to  partitioning  the  problem  into  activities/nodes  which  are  shown  as  boxes  and 
then  decomposing  the  higher  order  nodes  into  sublevel  ones,  another  important  aspect  of  this 
analysis  involves  the  use  of  arrows  entering  and  exiting  each  box. 

The  side  of  the  box  at  which  the  arrow  enters  or  leaves  denotes  its  interface  role  as  an  input, 
output,  control/constraints,  or  responsibility  as  shown  in  Figure  4-14. 

More  specifically,  arrows  entering  to  the  left  of  the  box  indicate  inputs,  while  those  to  the 

X 

right  indicate  flow  of  data  out  of  the  box.  Arrows  entering  the  top  of  the  box  represent  con¬ 
straints  placed  upon  the  responsible  agency’s  ability  to  accomplish  the  activity.  Arrows  entering 
the  bottom  of  the  box  represent/depict  the  agencies  responsible  for  the  activity. 


tThe  exiting  data  is  a  result  of  the  activity  taking  place  within  the  box. 
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CONTROLS/CONSTRAINTS 


Having  described  the  methodology  to  be  used  in  Figures  4-15  through  4-19,  the  analysis  of 
the  readiness  issue  will  be  presented.  The  reader  should  bear  in  mind  that  the  ultimate  purpose 
of  this  analysis  is  to  identify:  1)  the  facilities,  equipment  and  resources  required:  and,  2)  the  Air 
Force  agency^responsible  for  accomplishing  the  readiness  support  functions. 

Figure  4-15  depicts  the  basic  activity  associated  with  this  issue,  i.e.,  “Combat  Readiness 
Support  for  ECS  Based  Weapon  Systems.”  Input  factors  which  affect  this  activity  are  the 
environment  in  which  the  system  must  operate  and  the  level  of  technology  impacting  at  any 
point  in  time. 

The  following  are  constraints  placed  upon  the  Air  Force’s  ability  to  perform  this  activity. 

•  Weapon  system  design  and  the  ECS’s  role  within  this  weapon  system. 

•  Resources,  facilities,  and  equipment  available  to  provide  this  support. 

(Embedded  within  the  equipment  aspect  are  the  classic  software  tools 
and  yet-to-be-defined  data  bases.  Resources  available  refers  not  only  to 
manpower  and  monies,  but  also  expertise.) 

•  Tivte  available  to  provide  this  support.  A  classic  example  is  in  the  EW 
category  where  response  time  must  be  in  a  matter  of  hours  or  days  in 
order  to  support  the  operational  use  of  these  systems.  The  initial  investi¬ 
gation  into  the  readiness  issue  leads  to  the  belief  that  OFP’s  of  Fire  Con¬ 
trol  Radars,  certain  Navigation  equipment  (i.e.,  Terrain  Following 
Radars),  and  individual  Command  and  Control  Systems  (i.e.,  AW  ACS, 

JTIDS),  will  also  have  a  very  rapid  support  reaction  time  associated  with 
them.  In  conjunction  with  changing  the  OFP’s,  the  training  ranges  and 
exercise  evaluation  systems  must  also  be  changed  to  provide  realistic 
training. 

Arrows  entering  from  the  bottom  of  the  box  show  that  the  Air  Force  is  the  organization 
responsible  for  accomplishing  this  activity;  however,  within  the  Air  Force,  AFLC  has  the 
primary  responsibility  for  providing  this  support.  As  the  analysis  will  show,  this  responsibility 
requires  AFLC  to  assume  several  new  and  nontraditional  roles  in  order  to  provide  the  required 
support.  As  a  result,  it  is  important  that  roles  and  missions  be  fully  understood  so  that  critical 
AFLC  resources  are  not  expanded  in  duplicating  either  Operational  (User),  AFSC,  or  the  Intelli¬ 
gence  Communities  mission.  In  some  cases  where  it  would  appear  that  the  responsibility, 
according  to  “classic”  Air  Force  roles  and  Mission  definitions,  would  correctly  rest  with  other 
than  AFLC,  such  factors  as  unique  system  knowledge,  and  available  facilities  and  equipment 
dictate  that  AFLC  assumes  the  roles.  This  is  particularly  true  in  the  areas  of  intelligence  support 


+ 

'  Reference  is  made  to  the  “Air  Force  agency”  due  to  the  fact  that  although  most  of  the  respons¬ 
ibility  is  AFLC’s,  certain  other  Air  Force  organizations  play  a  key  role  in  this  process. 
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Figure  4-17.  Recognize  Change  Requirement 


Figure  4-18.  Assess  Situation 


and  threat  impact  analysis  work.  These  new  support  requirements  carry  with  them  their 
asociated  investment  in  equipment,  facilities,  and  resources. 

The  output  of  the  activity  is  rapid,  effective,  and  affordable  ECS  changes  to  the  fielded 
weapon  systems  (arrow  to  right  of  box  illustrates  this  flow). 

Figure  4-16  is  a  Level  2  breakdown  of  the  basic  “Combat  Readiness  Support  for  ECS  Based 
Weapon  Systems”  activity.  At  this  level  we  see  that  the  four  activities  required  are: 

1.  Recognize  change  requirement  (Node  (D) 

2.  Assess  »he  s!‘  lation  (Node  ©) 

3.  Select  ;e  engineer  ECS  change  (Node  (3)) 

4.  Disseminate  and  configuration  manage  the  ECS  Change  (Node  @) 

4.3.1  ECS  Readiness  Support  Activities 

The  following  paragraphs  amplify  on  the  ECS  readiness  support  activiiies. 


4. 3. 1.1  Recognize  Change  Requirement  (Node 


The  recognize  change  requirement  activity  requires  inputs  related  to  the  intelligence  situa¬ 
tion  and  the  operational  use  of  the  weapon  system.  The  constraints  placed  upon  ones  ability  to 
perform  this  activity  relates  to  the  availability  of  data  in  the  areas  of  intelligence  and  system 
knowledge.  Closely  aligned  with  these  constraints  is  the  access  the  people  required  to  perform 
this  activity  have  to  this  data.  The  responsibility  for  performing  this  activity  rests  with  AFLC 
and  the  operations  community.  The  output  from  this  activity  is  labeled  “Situation  Description” 
and  would  be  in  the  form  of  a  statement  of  the  intelligence  situation  and  the  systems  associated 
vulnerability. 


The  assessing  the  situation  activity  involves  taking  the  output  from  Node  1,  the  situation 
description,  and  combining  it  with  programmatic  and  technology  inputs.  The  programmatic 
inputs  refer  to  such  things  as  POM  funding  considerations,  weapon  system  modification 
schedule,  and  the  weapon  system’s  life  span  expectancy.  The  constraints  imposed  upon  the  ac¬ 
tivity  of  assessing  the  situation  are  in  the  areas  of  weapon  system  knowledge!  available  facilities 
and  equipment,  and  the  time  available  for  the  assessment.  The  responsibility  for  accomplishing 


^System  knowledge  refers  to  knowledge  of  the  current  OFP  configuration  and  the  system’s  ECS 
flexibility. 
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this  activity  rests  with  both  AFLC  and  the  operations  community;  however,  the  previously 
discussed  constraints  clearly  show  that  the  majority  of  this  responsibility  lies  with  AFLC.  The 
operational  communities  responsibilities  are  more  in  the  line  of  direction  and  guidance  once 
alternative  approaches  hove  been  determined.  (Discussed  in  detail  in  Section  4.3.3.)  Outputs 
from  this  activity  in  the  form  of  alternatives  will  be  provided  to  the  operational  community  and 
the  Node  3  activity. 


4. 3. 1.3  Select  and  Engineer  ECS  Change  (Node 

The  list  of  alternatives  provided  from  Node  2  are  combined  with  the  operational  communi¬ 
ties  direction  and/or  guidance  in  the  select  and  engineer  ECS  change  Node  3  activity.  One  of  the 
primary  constraints  placed  upon  the  Node  3  activity  is  the  AFLC  software  responsibility  task- 
ings.  Specifically,  the  ALC  tasked  with  this  responsibility  and  their  associated  facilities,  equip¬ 
ment,  and  resources  will  largely  determine  the  success  of  this  activity.  As  depicted,  AFLC  and 
more  specifically  the  particular  ALC  charged  with  the  weapon  system  'subsystem  support,  is  the 
responsible  agency. 

4. 3. 1.4  Disseminate  and  Configuration  Manage  the  ECS  Cnange  (Node  @) 

Once  the  ECS  change  has  been  determined  and  engineered,  AFLC  continues  to  have  the 
responsibility  to  disseminate  and  exercise  CM  control.  The  output  from  this  activity  is  the  actual 
ECS  change,  the  associated  T.O.’s  and  installation  guidance. 


Generally,  this  level  of  definition  of  the  problem  has  not  permitted  the  identification  of  all 
of  the  resources,  equipment,  facilities,  and/or  specific  responsibilities.  Therefore,  the  problem 
is  broken  down  into  the  next  functional  portion. 


By  further  partitioning  the  first  three  activities/nodes  depicted  in  Figure  4-16,  a  level  exists 
where  additional  ALC  responsibilities,  resources,  equipment,  facilities,  and  actions  for  accom¬ 
plishing  readiness  support  can  be  identified.  Figures  4-17  through  4-19  depict  this  partitioning. 
Following  a  brief  discussion  of  these  figures  and  their  associated  activities,  a  specific  set  of  re¬ 
quirements  for  accomplishing  these  activities  is  provided. 


^Alternatives  could  include;  hardware  modifications,  ECS  software  changes,  and/or  tactics 
considerations.  For  the  purposes  of  this  discussion,  on>y  the  ECS  software  change  alternative 
will  be  considered  and  further  examined. 
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As  depicted  in  Figure  4-17,  the  recognize  change  requirement  node  is  composed  of  the 
following  four  activities, 

Determine  the  System/Subsystem  Sensitivities  (Node  1.1).  This  activity  involves  the 
task  of  technically  evaluating  the  system/subsystem  as  to  its  sensitivity  to  the  antici¬ 
pated/actual  threat.  Classically,  this  task  is  accomplished  through  a  series  of  sensitiv¬ 
ity  analysis  activities  in  the  form  of  studies  and  evaluation.  The  ability  to  accomplish 
these  evaluations  is  highly  dependent  upon  detailed  system  knowledge,  technical 
skills,  availability  of  necessary  equipment,  available  resources,  and  availability  of 
operational  scenario  data.  The  responsibility  for  accomplishing  this  task  is  clearly  the 
ALC’s  system/subsystem  lead  engineer’s;  however,  support  is  required  from  the 
operational  user  in  the  form  of  current  operational  scenario  data.  The  outputs  of  this 
activity  are:  first,  a  description  of  the  system’s/subsystem’s  OFP  vulnerabilities;  and, 
secondly,  intelligence  collection,  production,  and  distribution  requirements.  The  final 
output  is  especially  significant  in  that  it  provides  the  basis  for  national  intelligence 
support.  Currently,  AFLC’s  lack  of  participation  in  the  classic  intelligence  cycle 
represents  a  serious  gap  in  the  Air  Force’s  intelligence  collection  and  production 
requirements  listings.  Significant  from  another  viewpoint  is  the  fact  that  only  the 
ALC  system/subsystem  lead  engineer  has  the  technical  insight  into  the  system/sub¬ 
system  OFP  which  would  allow  the  actual  statement  of  these  requirements.  Follow-on 
recommendations  will  amplify  on  this  area. 

Receive,  Store,  Produce,  and  Analyze  System/Subsystem  Related  Intelligence  Data 
(Node  1.2),  In  order  to  accomplish  the  task  of  determining  the  ECS  software  change 
necessary  to  offset  changes  in  the  threat  environment,  the  ALC  lead  engineer  and  his 
supporting  staff  must  have  access  to  both  historical  and  daily  intelligence  data.  This 
requires  access  to  a  current  and  complete  system/subsystem  related  technical  intelli¬ 
gence  data  baset,  appropriate  clearances,  data  storage,  work  facilities,  secure  com¬ 
munications,  inclusion  on  existing  intelligence  document/message  distribution  lists, 
and  intelligence  staff  support  within  the  ALC’s.  (See  Volume  II,  Phase  II  report  for 
additional  data  in  this  area.)  The  output  from  this  activity  is  in  the  form  of  intelligence 
assessments  and  intelligence  data  base,  collection,  and  production  requirements. 

Determine  Impact  of  Intelligence  (Actual/Possible)  on  System/Subsystem 
(Node  1.3).  This  activity  represents  the  heart  of  the  “recognize  change  requirement’’ 
process.  In  this  activity,  the  actual  system/subsystem  limitations  are  determined  as  a 
function  of:  first,  the  system’s/subsystem’s  OFP  sensitivities;  and,  secondly,  the 
actual  or  suspected  threat  environment  in  which  the  system/subsystem  may  be 
operated.  Up  to  this  point  how  the  classic  intelligence  assessment  process  supports  this 
activity  has  been  shown;  however,  there  are  at  least  two  other  very  significant 
methods  of  determining  actual  or  suspected  th  at  impact  on  the  system/subsystem 
ECS  software.  These  are  through  the  use  of  flight  data,  wherein  the  system/subsystem 
software  is  exposed  to  either  the  actual  environment  or  a  simulated  range  environ¬ 
ment;  and  the  use  of  laboratory  stimuli  device  wherein  the  system/subsystem  OFP  is 


^ln  the  EW  area,  the  Air  Force  has  developed  the  Electronic  Warfare  Integrated  Reprogram¬ 
ming  (EWIR)  data  base  for  this  purpose.  The  effort  to  develop  this  data  base  was  extensive  and 
required  a  great  deal  of  technical  insight  into  the  EW  systems’  software  structure. 
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subjected  to  either  actual  or  suspected  environmental  conditions.  Both  of  these 
approaches  are  necessary  and  require  specific  tools,  facilities,  and  resources  which  will 
be  discussed  in  the  form  of  requirements  in  follow-on  paragraphs.  The  responsibility 
for  accomplishing  the  above  tasks  rests  with  the  system/subsystem  lead  engineer  and 
his  staff  with  support  from  the  operational  user  in  the  form  of  scenario/concept  of 
operations  data. 

Generate  Situation  Description  (Node  1.4).  While  this  activity  on  the  surface  appears 
to  be  an  administrative  function  and  in  some  cases  not  an  actual  requirement,  it  is 
included  for  the  following  reasons. 

•  Cases  wherein  a  subsystem  (item)  manager  wants  to  communicate 
his  findings  to  the  system  manager  need  depiction. 

•  The  documentation  at  this  level  could  very  well  be  reflected  in  either 
an  ECP  request,  a  SOW,  or  serve  as  the  foundation  for  additional 
resource  requests. 

•  At  a  minimum,  historical  data  as  a  result  of  this  recognize  change 
requirement  activity  should  be  documented  and  stored  for  future 
reference. 

4.3.2  ECS  Readiness  Support  Requirements 

The  overall  requirements  for  readiness  support  are  depicted  in  Figures  4-15  through  4-19  as 
activities.  The  following  paragraphs  discuss  these  activities  in  the  form  of  requirements.  These 
requirements  in  turn  must  be  satisfied  through  a  series  of  actions  on  the  part  of  AFLC.  The  for¬ 
mat  used  is  to  first  identify  and  discuss  the  basic  requirement  and  then  describe  the  action 
recommended  to  accomplish  this  requirement. 

The  following  paragraphs  present  the  basic  requirements  which  AFLC  must  satisfy  in  order 
to  initially  provide  readiness  support.  This  list  of  requirements  and  actions  is  not  intended  to  be 
all  inclusive;  rather,  it  represents  a  minimum  list  of  activities  necessary  to  place  AFLC  in  an  in¬ 
itial  position  to  provide  readiness  support.  Additional  requirements  and  actions  can  only  be 
identified  through  an  evolutional  process  based  upon  day-to-day  support  needs. 

4 . 3. 2 . 1  Requirement  1;  Determining  Those  Systems/Subsystems  Which  Should  be  Included 
Under  the  Readiness  Support  Concept 

This  determination  activity  should  include  not  only  those  system/subsystems  which  have 
actually  transitioned  to  AFLC,  but  also  those  which  are  in  development.  Once  this  listing  of 
systems/subsystems  is  established,  it  should  be  maintained  within  an  AFLC  data  base  manage¬ 
ment  system.  Purpose  for  establishing  this  listing  is  twofold;  first,  to  obtain  a  comprehensive 
listing  of  these  systems/subsystems  and  the  specific  AFLC  responsible  for  their  support;  and 
secondly,  to  lay  the  groundwork  for  future  resource  justifications. 
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Recommended  Actions 


1.  Generically  identify  the  characteristics  of  the  system/subsystem  ECS 
which  qualify  them  for  inclusion  under  the  Readiness  Support  Concept. 

Use  these  characteristics  to  facilitate  actions  2  and  3  below. 

2.  Initiate  action  with  the  ALCs  to  obtain  initial  listing  of  the  system/sub¬ 
systems  for  inclusion  under  Readiness  Suppcrt  Concept. 

3.  Initiate  AFL.C  interface  with  AFSC  to  explain  the  Readiness  Support 
Issue  and  request  status  of  ECS  under  development.  Criteria  for  selecting 
ECS  to  be  identified  should  be  developed  and  distributed  to  all  AFLC 
organizations  for  their  use  in  this  effort  (see  1  above). 

4.  In  coordination  with  the  operational  useis,  consolidate  and  approve  a 
listing  of  these  systems/subsystems  which  should  be  included  under  the 
Readiness  Support  Concept.  On  a  yearly  basis,  this  listing  should  be 
renewed  and  prioritized  in  preparation  for  the  POM  cycle. 

5.  Designate  responsible  Headquarters  agency  for  consolidaticn/maintain- 
ing  Readiness  Support  system/subsystem  listing. 

4. 3. 2. 2  Requirement  2:  Determining  the  Systems  Subsystems  ECS  Software  Sensitivities 
Through  Appropriate  Sensitivity  Analysis  Studies  and  In-House  Efforts 

Typical  systems  which  fall  under  this  category  are  OFP’s  of  fire  control  radars,  AW  ACS, 
E-4,  JTIDS,  GPS,  Seek  Talk  and  the  various  cruise  missiles.  Specifically,  the  studies  should 
address  the  following  functions. 

1.  System/subsystem  vulnerabilities  as  a  function  of  changes  in  the  actual/ 
expected/possible  adversary  ECM  waveform,  numbers  of  systems,  and 
tactical  employment  of  these  systems. 

2.  Possible  generic  ECS  software  alternative  which  could  be  usea  to  offset 
the  changes  discussed  in  1 . 

3.  Specific  intelligence  collection  and  analysis  efforts  which  should  be  ini¬ 
tiated  in  order  to:  complete  1  and  2;  alert  the  system/subsystem  manager 
of  significant  changes  in  the  threat  environment  which  could  impact  on 
system/subsystem  perfromance;  and,  protect  against  adversary 
technological  surprise  while  laying  the  foundation  for  preemptive 
engineering  efforts. 

Recommended  Actions 

1.  Using  prioritized  listing  obtained  from  actions  in  support  cf  Require¬ 
ment  1,  funding  for  sensitivity  analysis  studies  should  either  be  identified 
from  existing  sources  or  programmed  into  future  POM  requests. 

2.  Issue  Statement  of  Works  (SOW’s)  for  selected  systems/subsystems  sens¬ 
itivities  analysis  studies.  (Headquarters  oversight  of  these  SOW’s  should 
be  maintained  ensure  different  studies  are  supportive,  minimize 
duplication,  and  request  similar  r.ctions/deliverables.) 
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3.  Include  as  part  of  alt  future  PMD’s  the  requirement  that  sensitivity 
analysis  data  be  provided  as  part  of  the  development  process. 

4. 3. 2. 3  Requirement  3:  Establishing  the  Capability  and  Resources  Required  to  Receive,  Store, 
Produce  and  Analyze  System/Subsystem-Related  Classified  Intelligence  Data 

This  effort  should  be  accomplished  in  conjunction  with  AF/IN,  Foreign  Technology  Divi¬ 
sion  (FTD),  National  Security  Agency  (NSA),  Defense  Intelligence  Agency  (D1A),  and  the 
operational  users.  In  the  area  of  AFLC  resources  required  to  support  this  capability,  the  follow¬ 
ing  comments  are  offered. 

1.  AFLC  Headquarters.  Currently  AFLC  has  within  the  AFLC/XR 
organization,  a  core  capability  to  build  the  necessary  Headquarters  sup¬ 
port  around.  Areas  this  group  should  address  include:  policy  formula¬ 
tion  and  AFLC/Air  Force  regulation  writing/modifications;  interface 
with  AF/IN  in  the  areas  of  ALC  engineer  and  staff  access  justification, 

"billet”  authorizations,  and  ALC  vault  and  secure  communication 
requirements;  consolidation  and  formulation  of  AFLC  collection  and 
analysis  requirement"-  consolidt  ion  and  formal  submissions  of  AFLC 
data  base  and  distribution  requirements;  and  training  and  guidance  to 
ALC  staff  and  engineers  in  the  intelligence  process  covering  the  spectrum 
from  requirements  definition  to  information  dissemination  and  storage. 

Exact  size  and  specific  makeup  of  this  headquarters  staff  cannot  be 
determined  without  the  formal  assistance  of  AF/IN. 

2.  ALC.  Within  the  various  ALC’s,  a  staff  function  must  be  established  to 
perform  the  following: 

a.  Receiving,  processing,  storing,  and  safeguarding  classified 
intelligence; 

b.  Actually  writing  the  "billet”  justification  requests,  providing 
access  briefings/debriefings,  and  maintaining  access 
authorization; 

c.  Writing  and  submission  of  the  ALC’s  intelligence  collec¬ 
tion/analysis  requirements; 

d.  Intelligence  data  base  storage  and  access  support; 

e.  Day-to-day  screening  and  processing  of  new  intelligence  data; 
and 

f.  Interface  on  behalf  of  the  ALC  management  and  engineers 
with  “classic”  intelligence  organizations. 
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Recommended  Actions 


1. 


2. 


Initiate  formal  discussions/briefings  with  AF/1N.'  Purpose  i>  to  inform 
AF/1N  of  the  problem  and  solicit  support  in  the  following  areas. 


a. 

b. 


d. 

e. 

f. 

8- 

h. 


k. 


m. 


n. 


“Billet”  justifications 
Clearances 

Secure  communication,  storage,  and  vault  requirement 
definition 

Intelligence  AFSC  identification  and  authorization  pro¬ 
cedures 

POM  support  in  Programs  3  and  6 
Training 

Understanding  of  sources  of  data  and  access  requirements 

Foreign  Technology  Division  and  National  Agencies  respons¬ 
ibilities  and  support  loies 

Data  basefsj  status  and  procedures  for  estab- 
lishment/modifi-ations 

Air  Force  Intelligence  Service  (AF1S)  operating  locations 
(OL)  responsibilities  and  available  support;  specifically, 
A  FIS  OL-F  and  OL-N  at  TAWC  and  Electronic  Warfare 
Center  have  AF/1N  support  responsibilities  which  may  be 
directly  applicable  to  the  AFLC  problem 

AFLC  Headquarters  and  ALC  Staff  responsibilities  and 
functions  as  they  relate  to  the  Air  Force  Intelligence  Support 
Mission 

Collection,  analysis,  and  production  requirements  process 
Definition  of  roles  and  missions 
Idenification  of  special  access  requirements 


Established  contact  with  NSA/W07  and  DIA/DT-4C.  These  organiza¬ 
tions  are  specifically  tasked  within  their  respective  agency  with  the 
responsibility  of  interface  with  their  operational  users.  It  is  important 
that  the  Headquarters  AFLC  and  ALC  stall  understand  these  organiza¬ 
tions  responsibilities  and  support  roles. 

Establish  contact  with  the  opeiational  usets  (TAC,  SAC.  MAC,  aDTC) 
for  purpose  of  making  them  aware  of  the  readiness  support  issue  and 
intelligence  requirements.  This  is  extremely  important  due  to  the  fact  that 
these  users  historically  have  stated  the  Air  Force  intelligence  require- 
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ments  for  collection,  analysis,  production  and  data  base  definition.  They 
are,  therefore,  very  much  aware  of  the  procedures  and  problems  in  this 
area  and  can  serve  as  a  great  source  of  information  and  assistance. 

4 . 3 . 2 . 4  Requirement  4:  Obtaining  the  Necessary  Access  to  the  Required  (3  Above)  Classified 
Intelligence  Data 

Volume  11  (Phase  II  report),  provides  insight  into  the  type  access  required.  Specific 
justification  must  be  written  for  the  necessary  engineers  and  managers.  AF/1NS  and  AF/INY 
can  provide  valuable  assistance  in  this  area;  however,  prior  to  initiation  of  activity  in  this  area, 
Headquarters  AFLC  should  ensure  that  AF/1N  fully  understands  the  AFLC  initiatives  and 
needs  in  this  area.  Formal  message  traffic  and  appropriate  educational  briefing/discussion 
between  Headquarters  AFLC  and  AF/IN  should  be  initiated.  (Actions  required  in  this  area  are 
outlined  under  Requirement  3.)  A  clear  understanding  of  the  AFLC  requirements  and  full 
AF/IN  support  is  essentia!  in  this  area  due  to  the  physical  constraints  associated  with  current  Air 
Force  “billet”  authorizations.  It  is  very  possible  that  a  formal  Air  Force  request  for  additional 
Air  Force  billets,  along  with  proper  justifications,  may  be  necessary.  In  such  a  case,  AF/IN  must 
fully  understand  and  be  in  a  position  to  submit,  justify,  and  defend  such  a  request. 

4 . 3 . 2 . 5  Requirement  5:  Establishing  the  Capability  to  Determine  the  Impact  of  Actual  or  Sus¬ 
pected  Threat  Data  on  the  System/Subsystem  ECS  Software 

This  includes  the  establishment  or  modifying  of  Integrated  Support  Stations  (lSS)/Integra- 
tion  Suppor  Facilities  (ISF)  to  allow  the  stimulation  of  the  system/subsystem  software  by  repre¬ 
sentative  threat  data.  In  addition,  appropriate  data  reduction  capabilities  must  be 
developed/modified  to  support  this  effort.  Required  ECS  change/modification  response  tirne^ 


^Refers  to  the  maximum  length  cf  time  available  to  accomplish  the  four  activities  depicted  in 
Figure  4-16  and  Drovide  the  ECS  change  to  the  field.  In  most  cases,  this  “rr  ,ponse  lime”  will 
include  considerations  of  the  following  factors: 

a.  Operational  users  requirements  based  upon:  the  systens/subsysiems 
mission;  operational  scenario;  and  sysiem/subsystem  numbers  and 
backup  procedures.  (In  almost  all  cases,  the  Operational  Users  Re¬ 
quirements  dictate  the  response  time.) 

b.  Communications  availability  and  mediums. 

c.  AFLC/ALC  system /subsystem  support  capabilities.  [Careful  con¬ 
sideration  must  be  given  in  this  area  to  ensure  that  limited  support 
capabilities  do  not  unrealistically  restrict  (a)  above.  In  most  cases,  (a) 
dictates  the  modification/developmem  of  the  required  suppon 
capabilities  and  serve  as  justification  for  these  capabilities.] 
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of  the  various  systems/subsystems  identified  under  Requirement  1  is  a  key  factor  in  determining 
the  type  ISS/ISF  development/modification  effort  necessary  in  this  area. 

Recommended  Actions 

vSame  as  those  for  Requirement  6.) 

4 . 3 . 2 . 6  Requirement  6:  Developing  Within  the  Various  ISF  a  Stimulus  Device  for  Simulating 
the  Actual/Suspected  Threat  Environment 

The  readiness  support  requirement  dictates  that  parametric  stimulus  devices  be  used  in  con¬ 
junction  with  and  in  preparation  for  ECS  software  evaluation/modification  work.  These 
stimulus  devices  can  range  from  very  elaborate  open  loop/close  loop  simulation  systems  which 
support  an  entire  ALC  or  system,  to  straightforward  simulation  at  the  subsystem  IF  level.  The 
type  device/devices  required  must  be  determined  as  a  function  of:  ALC  responsibility, 
systeiit/subsystem  relationship  and  physical  support  locations,  and  system/subsystem  complexi¬ 
ties  and  readiness  support  priority. 

Recommended  Actions 

1.  Using  the  approved  system/subsystem  list  from  Requirement  !,t  the 
operational  users,  at  the  command  level,  should  be  queried  for  their 
response  time  requirements  on  a  system/subsystem-by-system/subsystem 
basis. 

2.  Initiate  HQ  AFLC  actions  to  consolidate  and  obtain  user  coordination 
on  the  required  response  time  for  each  system/subsystem.  This  list 
should  be  reviewed  periodically  (yearly)  and  forms  the  basis  for  future 
resource  justification  and  PMD  actions. 

3.  Current  support  capabilities  for  the  system /subsystem  identified  in  i  and 
2  should  be  solicited  from  the  various  ALC. 

4.  Contractual  efforts  should  be  initiated  by  the  various  system/subsystem 
managers  to  ascertain  current  support  deficiencies  in  the  form  of  specific 
recommendations  and  top  ievel  specifications  for  individual  support  sta¬ 
tion  (ISS)  data  reduction  capabilities,  software  tools  development,  and 
stimulus  devices  acquisition/development.  In  addition,  this  contractual 
activity  should  provide  recommendations  as  to  the  ALC  approach  to  this 
problem  as  far  as  indridual  ISS,  ISF,  and/or  ALC  requirements.  For 
example,  these  recommendations  should  address  the  issues  of  individual 
stimulus,  software  tools,  data  reduction  capabilities  on  an  ISS  versus  ISF 
versus  ALC  basis. 


*The  resuits  from  the  various  sensitivity  analysis  studies  (Requirement  2)  will  also  have  an 
impact  in  satisfying  Requirement  6;  however,  ii  is  not  necessary  to  await  the  results  prior  to  ini¬ 
tiating  activities  associated  with  this  requirement. 
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5.  Data  obtained  from  4  should  be  consolidated  by  HQ  AFLC  and  used  for 
POM  considerations. 

6.  Initiate  contact  with  the  ASD  Simulator  SPO  to  obtain  support  in  future 
stimulus  development  efforts.  Specific  areas  of  support  include:  pro¬ 
viding  inputs  as  to  desired  results  of  4,  and  funding  support  in  4  and 
future  development  efforts. 

7.  HQ  AFLC  as  a  participating  command  in  the  Air  Force  simulation 
validation  should  ensure  that  any/all  stimulus  devices  developed  in  sup¬ 
port  of  this  concept  are  included  in  the  Air  Force  simulation  validation 
program. 


In  many  cases,  this  requires  the  development  and  installation  of  flight  data  recording  and 
associated  data  reduction  equipment  onboard  various  aircraft.  With  the  development  of  the 
Electronic  Warfare  Close  Air  Support  (EWCAS)  Range,  and  future  SAC  and  TAC  range 
development  programs,  this  requirement  becomes  even  more  important.  Embedded  within  this 
requirement  is  a  necessity  to  investigate  the  feasibility  of  designing  the  capability  to  record  ECS 
memory  and  register  data  during  actual  flight  tests.  This  would  allow  the  systematic  evaluation 
of  actual  system/subsystem  performance  against  the  ECS’s  operation/performance  at  both  the 
Blue  Tape  (Mission  Data)  and  Red  Tape  (OFP)  level  in  a  dynamic  range  environment.  The 
advantages  of  this  approach  versus  the  traditional  1SS  approach  are  in  the  area  of  system/sub¬ 
system  performance  as  a  function  of  the  actual  flight  environment;  provided,  of  course,  the 
flight  environment  includes  a  realistic  simulation  of  true  combat  conditions,  especially  the  elec¬ 
tronic  environment.  (See  Requirement  12.) 

Recommended  Actions 

I .  As  this  area  may  require  both  advance  technology  and  actual  avionics 
system  development  efforts,  AFLC  should  initiate  contact  in  the  form  of 
a  request  for  support  with  both  Air  Force  Avionics  LAB  and  the  ASD 
development  community.  Specific  AFLC  requests  should  be  in  the  form 
of  requirements  for  ASD/AFAL  to  investigate  the  feasibility  of  design¬ 
ing  the  capability  to  record  ECS  memory  and  register  data  during  execu¬ 
tion  of  the  ECS  (Blue  Tape)  and  OFP  (Red  Tape)  under  actual  flight  con¬ 
ditions.  The  feasibility  study  should  address 

a.  State  of  technology  in  this  area, 

b.  Complexity  of  retrofitting  such  a  capability  to  systems/sub¬ 
systems  identified  in  Requirement  1,  and 

c.  Desirability  of  including  such  a  requirement  as  a  basic  ele¬ 
ment  in  the  development  of  all  future  ECS  systems. 
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2.  Initiate  actions  at  the  system/subsystem  manager  level  to  install  flight 
data  recording  and  associated  data  reduction  equipment  aboard  the  key 
aircraft. ' 

3.  Initiate  actions  to  modify  existing  1SS/ISF  in  response  to  2. 

4. 3. 2. 8  Requirement  8:  Obtaining  Operational  User  Support 

As  Figures  4-1! ’>  through  4-19  illustrate,  a  key  player  in  this  area  is  the  operational  user. 
With  one  possible  exception,  the  investigation  of  this  issue  indicates  that  the  operational  user  is 
largely  unaware  of  the  significance  and  magnitude  of  the  readiness  support  issue  on  his  combat 
capability.  The  one  exception  is  in  the  EW  category,  wherein  the  operational  community  is 
heavily  involved  and  knowledgeable  of  the  WR  MMR  EW  support  role.  To  be  successful  in 
obtaining  the  resources  required  to  perform  this  readiness  support  and  to  ensure  Air  Force 
organizational  roles  and  mission  are  understood  and  accomplished,  AFLC  should  solicit 
immediate  involvement  by  the  operational  user  and  Air  Staff  in  this  area.  In  addition  to 
conducting  an  educational  dialogue  with  the  operational  user  concerning  the  complexity, 
expense  and  criticality  of  the  readiness  support  issue,  AFLC  must  obtain  timely  operational 
scenario  data  for  use  in  determining/evaluating  ECS  software  changes. 

Recommended  Actions 

1.  Initiate  formal  discussions/briefings  with  the  operational  users  (TAC, 

SAC,  MAC  and  ADTC).  Purpose  would  be  to  inform  the  operational 
users  of  the  issue/problem  and  solicit  support  in  the  areas  of 

a.  Future  POM  requests, 

b.  Operational  scenario  data,  and 

c.  Assistance  and  coordination  on  the  prioritized  system/sub¬ 
system  list  obtained  from  Requirement  1. 

2.  Request  the  operational  users  to  identify  this  issue  as  a  readiness  support 
requirement  in  future  POM  activities.  In  addition,  support  for  the  partic¬ 
ular  system/subsystems  identified  under  Requirement  1  should  be  ranked 
accordingly  in  the  operational  users  POM  request. 

3.  Request  definitive  partitioning  of  responsibilities  in  this  area.  Figures 
4-14  through  4-19  should  be  used  to  articulate  this  partitioning. 


^Key  aircraft  can  be  obtained  by  reviewing  the  prioritized  list  obtained  from  Requirement  1 
along  with  discussion/coordination  with  the  operational  community. 
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4.  Request  parallel  action  within  the  operational  user  community  to  support 
this  activity.  This  action  could  take  the  form  of  identification  of  focal 
points/responsible  agencies  along  with  their  specific  functions.  An  exam¬ 
ple  would  be  the  designation/establishment  of  an  organization  within  the 
TAWC  similar  to  TAWC/ERW  whose  responsibility  is  operational  sup¬ 
port  to  fire  control  radars  ECS  mission  data. 

4. 3. 2. 9  Requirement  9:  Establishing  Preemptive  Engineer  Capabilities 

Preemptive  engineering  involves  the  “art  and  science’’  of  preemptively  engineering 
expected  ECS  software  changes  based  upon  predicted/postulated  and  highly  classified  technical 
intelligence  data.  To  accomplish  this  activity  requires  most  of  the  capabilities  discussed  in 
Requirements  1  through  8  above  with  the  key  ingredient  in  all  these  areas  being  access  to  highly 
sensitive  intelligence  data  at  the  ALC  lead  engineer/staff  level. 

Recommended  Actions 

1.  Initiate  the  required  actions  under  Requirement  1  through  8. 

2.  Initiate  formal  action  with  the  Air  Staff,  the  operational  users  and  Air 
Force  Intelligence  to  define  a  coordinate  Air  Force  concept  of  operations 
in  this  area.  Following  are  specific  areas  which  should  be  addressed 
under  this  concept  of  operation. 

a.  Systems/subsystems  to  be  included.  Requirement  1  provides 
the  basis  for  this  list. 

b.  Sources  of  the  intelligence  estimates  the  procedures  for 
obtaining  Air  Force  approval  of  the  estimates.  This  is 
especially  important  due  to  the  funding  impacts  and  DOD 
Directive  4600.3  and  3100.9 

c.  Roles  and  mission  and  associated  responsibilities. 

d.  Air  Force  Regulation  impact.  To  be  supportable,  this  concept 
must  be  included  in  the  appropriate  Air  Force  Regulations. 
Regulations  which  should  be  renewed  and  possibly  modified 
are  the  800  series  and  200-1. 

e.  Funding  options  and  POM  procedures. 

4.3.2.10  Requirement  10:  Enhance/Develop  the  Integrated  Support  Stations/Integrated  Sup¬ 
port  Facility  Concept  to  Respond  to  the  Readiness  Support  Requirement 

This  requirement  is  illustrated  in  Figures  4-17,  4-18,  and  4-19  with  its  subelements  discussed 
in  the  following  paragraphs. 

1 .  The  Recognize  Change  Requirement  Function  and  its  implications  on  the 
1SS/ISF  concept  is  discussed  under  Requirement  1. 
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2.  Figure  4-14  and  the  activities  of:  reviewing  the  situation  description  (Box 
2.1);  reviewing  the  system/subsystem  ECS  software  flexibility  (Box  2.2); 
and  determining  the  ECS  software  alternatives  (Box  2.3),  require  addi¬ 
tional  software  tool  development  in  the  area  of  analysis,  data  base 
management,  emulation,  and  data  reduction.  Of  the  tools  mentioned, 
the  development  ot  the  ones  associated  with  emulation  and  data  reduc¬ 
tion  are  the  most  critical  in  the  near  term.  Automated  data  base  manage¬ 
ment  tools  should  be  developed/enhanced  to  provide  historical  engineer¬ 
ing  data  associated  with  the  recognize  change  requirement  and  assess  the 
situation  (Figures  4-17  and  4-18)  activities  and  also  to  provide  access/ 
storage  of  programmatic  and  technology  related  data  (Figure  4-18,  Box 
2.3).  Correctly  constructed,  the  data  management  tool  discussed  should 
provide  the  AFLC  manager,  and  the  system/subsystem  lead  engineer  and 
his  staff  with  fingertip  access  to  historical  data  associated  with  the 
system/subsystem  of  concern.  The  time  of  response  associated  with  such 
systems/subsystems  as  fire  control  radars,  OFP’s,  AW  ACS,  E-4,  JT1DS, 
GPS,  EW,  and  ATD  dictates  the  development  of  such  tools. 

Recommended  Actions 


1.  Initiate  the  actions  required  to  develop  emulation  and  data  reduction 
software  tools  for  these  systems/subsystems  listed  as  a  result  of  Require¬ 
ment  1 

2.  Initiate  contractual  activities  to  develop  th»  top  level  specifications  for  an 
ECS  automated  data  base  management  system.  As  dismissed  in  other  sec¬ 
tions  of  this  study,  such  an  automated  data  base  management  system  is 
required  to  support  the  entire  ECS  effort.  Readiness  support  is  only  a 
subset  of  this  larger  requirement. 

4.3.2.11  Requirement  11:  Ability  to  Provide  ECS  Software  Configuration  Management  Con¬ 
trol  During  Crisis/Quick  Reaction  Periods 

To  appreciate  the  significance  of  this  issue  under  the  readiness  support  concept  versus  the 
routine  day-to-day  AFLC  operation,  one  must  envision  changing  ECS  software  to  various 
system/subsystem  MODS  in  a  matter  of  hours  or  days  wnile  attempting  to  maintain  CM  pro¬ 
cedures.  The  EW  category  again  is  a  prime  example  of  the  complexity  associated  with  this  area, 
particularly  in  a  crisis/conflict  environment  where  WR  MMR  must  rapidly  modify  and  CM  the 
various  radar  warning  receiver  versions/MODS.  Loss  of  CM  during  this  type  of  activity  could 
be  detrimental  to  the  combat  capability  of  a  particular  weapon  system.  From  another  respect, 
consider  the  F-16  and  F-15  radars  and  their  various  MODS  and  the  requirement  to  quickly 
modify  and  CM  changes  to  these  systems.  To  fully  understand  this  area,  AFLC  should  initiate 
efforts  to  monitor  and  document  exercises  associated  with  ECS  software  changes  under  stress 
conditions  associated  with  QRC/limited  time  response.  EW  “Loud  Byte”  exercises  offer  an 
excellent  “first  cut”  insight  into  this  problem  area. 
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Recommended  Actions 


1.  Initiate  efforts  to  conduct  a  “Loud  Byte'*  exercise  for  the  purpose  of 
documenting  CM  problems. 

2.  Develop  and  conduct  an  exercise  of  a  rapid  change  to  a  fire  control  radar 
OFP.  Use  the  timing  data  developed  under  Requirement  6  for 
establishing  the  exercise  scenario. 

3.  Based  upon  this  documentation,  draft  top  level  requirements  for  a  CM 
system  specifically  tailored  to  the  readiness  support  requirements.  Again, 
the  purpose  is  to  document  CM  problems. 

4.  As  the  final  products  of  this  effort  are  top  level  specifications,  AFLC 
should  consider  contractual  efforts  to  satisfy  this  requirement. 

4.3.2.12  Requirement  12;  Develop  a  Compatibility  to  Rapidly  Update  Training  Ranges,  Threat 
Simulators,  and  Aircrew  T raining  Devices 

Without  a  highly  trained  operator,  familiar  with  the  electronic  battlefield,  the  most  up-to- 
date  weapon  system  cannot  meet  the  challenge  of  todays  needs.  If  it  is  possible  to  change  OFF 
parameters  in  hours  or  days,  then  training  facilities  should  receive  similar  attention.  The  need 
for  realistic  training  was  clearly  stated  by  the  Joint  Chiefs  of  Staff  in  MOP-185.  “Training,  exer¬ 
cises,  and  testing  are  essential  elements  of  military  preparedness  and  must  receive  continued 
emphasis  during  peace  time.”  AFLC  should  initiate  efforts  to  keep  range  simulations,  jammers, 
and  evaluation  tools  up-to-date  with  enemy  capabilities. 

Recommended  Actions 

1.  Establish  a  system  for  identifying  potential  training  range  equipment 
deficiencies  by  comparing  the  baseline  with  enemy  threat  data.  (See  Re¬ 
quirement  9.) 

2.  Develop  a  capability  to  support  the  TAF/SAC/ECS  by  providing 
realistic  EW  and  C*  countermeasure  training  and  exercise  evaluation 
tools. 

3.  When  new  threats  are  encountered,  develop  a  quick  reaction  capability 
to  update  ECS  software  in  threat  simulations. 

4.4  ECS  SUPPORT  NETWORKS 

There  is  an  ever-growing  need  for  information  exchange  between  the  various  ECS  support 
elements  of  AFLC.  Technological  improvements  in  recent  years  have  pregressively  made  data 
networks  more  cost  effective.  The  purpose  of  this  section  is  to  present  information  to  facilitate 
AFLC’s  consideration  of  the  kind  of  networks  needed  and  an  approach  to  acquiring  these  net¬ 
works. 
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The  first  data  communications  systems,  established  some  two  decades  ago,  used  the 
telephone  voice  network.  The  telephone  network  is  an  invaluable  resource  capable  of  bringing 
computer  power  to  wherever  there  is  a  telephone.  Certain  problems  prevent  the  telephone  from 
being  the  panacea  to  all  networking  requirements.  An  example  of  these  problems  is  noise.  The 
human  ear  is  a  magnificant  terminal,  thus  it  filters  out  extraneous  noise  and  accepts  only  the 
relevant  information.  Computer  terminals  are  not  that  discerning  and  often  misinterpret  noise 
as  meaningful  data  which  result  in  errors.  Just  as  the  telephone  network  was  established  for 
voice  communications,  AFLC’s  networks  should  be  established  for  data  communications. 

A  computer  network  is  a  tool.  It  is  a  provider  of  a  service  that  is  used  by  the  programs  run¬ 
ning  on  the  network.  In  contrast  to  a  computer  operating  system  which  provides  such  services  as 
a  file  system  and  program  schedules,  a  netwufk  provides  the  service  of  communications.  Net¬ 
works  provide  or  create  a  mechanism  whereby  programs  and  resources  residing  in  computers 
attached  to  the  network  may  communicate  and  exchange  information.  To  design  a  network 
without  taking  into  account  the  characteristics  of  this  communication  and  the  requirements  of 
the  communicat.ng  resources  would  be  a  fruitless  task. 

The  leal  network  design  approach  begins  with  an  examination  of  user-level  requirements. 
These  requirements  must  take  into  account  the  functions  and  performance  as  well  as  availability 
and  flexibility.  In  other  words,  user  task  requirements  are  extended  into  a  set  of  network  func¬ 
tional  requirements.  The  functional  requirements  are  decomposed  into  layers  using  the  decom¬ 
position  criteria  of  physical  boundaries  and  available  technology.  Specific  algorithms  are 
designed  for  the  functions  while  considering  the  degree  of  centralization,  level  of  dynamic 
operation,  and  supported  topologies.  All  this  is  done  with  the  goals  and  requirements  of  the 
users  and  the  network  system  in  mind.  For  the  functions  that  are  now  distributed,  protocols  are 
designed  meeting  the  requirements  of  the  algorithms.  The  layers  are  then  placed  one  upon 
another,  their  interactions  examined,  available  technologies  and  services  investigated,  and  the 
design  process  reiterated  until  a  balance  or  compromise  is  reached  between  the  user  interfaces, 
system  goals,  and  available  service  mechanisms.  This  is  the  process  of  designing  a  network  archi¬ 
tecture.  In  reality,  the  process  must  also  deal  with  individual  personalities,  political  interests, 
parochailism,  and  other  possibly  conflicting  goals. 

Although  the  material  presented  in  this  section  mav  seem  to  apply  more  broadly  to  long 
distance  networks,  the  actual  difference  between  local  and  long  distance  is  so  small  that  the 
discussion  can  apply  to  both  network  types. 
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A  local  network  is  a  data-communications  sysiom  designed  to  interconnect  computers  and 
terminals  over  a  restricted  geographical  area.  At  a  technical  level,  the  problems  involved  in 
designing  local  networks  are  not  very  different  from  Ion?  distance  networks,  but  the  parameters 
are  different.  Son.e  of  the  differences  are 

•  Higher  transmission  rates  (the  communications  network  and  transmis- 
sijn  medium  are  generally  not  bottlenecks), 

•  Lower  delay  (delivery  delays  are  shorter), 

•  Lower  error  rates  compared  with  typical  long  distance  transmission 
media, 

•  Lower  cost  to  interconnect  terminal  and  computer  equipment,  and 

•  Greater  use  of  broadcast  or  multi-address  communications. 

From  an  organizational  perspective,  a  local  network  is  likely  to  be  designed  and  implemented  by 
a  single  organization.  Likewise,  a  single  organization  is  likely  to  be  responsible  for  its  operation. 
This  results  ir.  a  much  higher  degree  of  control  than  can  be  expected  in  a  long  distance  network, 
eliminating  such  problems  as  coordinating  changes  among  several  different  groups,  the  “finger¬ 
pointing”  problem  of  fauit  diagnosis,  etc. 

It  is  clear  that  there  is  no  sharp  division  between  long  distance  and  local  networks;  rather 
there  is  a  continuance  in  which  smaller  geographical  areas  are  served  with  higher  speed,  lower 
cost  interfaces. 

The  outline  of  this  network  section  is  depicted  in  Figure  4-7.0.  This  pictorial  description 
shows  that  the  current  ECS  support  posture  coupled  with  long  range  objectives  combine  into 
total  ECS  support  requirements  for  the  future.  Networking  can  assist  in  the  solution  of  a  por¬ 
tion  of  the  total  ECS  support  requirements.  The  actual  network  design  will  result  from  consider¬ 
ation  of  the  elements  of  design  shown  as  contrasted  with  each  other  and  with  the  network 
Requirements  themselves.  Finally,  a  recommended  sequence  of  necessary  activities  to  acquire  the 
data  network(s)  is  listed. 

4.4.1  ECS  Support  Networks  Requirements 

The  requirements  for  AFLC  data  networks  are  the  product  of  the  composite  of  automation 
of  ECS  support  processes,  modular  ISF’s,  training  system,  ana  all  other  considerations  which 
alleviate  current  and  projected  ECS  support  deficiencies.  This  requirements  section  translates  all 
these  items  into  functional  requirements  for  data  networks.  Specifically,  each  ECS  support 
requirement  will  be  reviewed  for  its  applicability  to  a  partial  or  whole  data  networking  solution. 
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The  composite  of  these  requirements  reviews  indicates  the  total  network  requirements.  For  ease 
of  reference  purposes,  each  requirement  reviewed  is  assigned  an  identifying  number.  Functional 
ECS  support  requirements  for  data  networks  will  be  related  to  these  identifying  numbers. 

4. 4. 1.1  Requirement  1;  ECS  Change 

This  requirement  is  made  up  of  the  subelements  of :  receive  and  process  change  ECS  soft¬ 
ware  requests,  prelimirary  analysis  and  problem/deficiency  definition,  and  preliminary  resource 
allocation  and  scheduling.  Each  of  these  subelements  implies  use  of  a  large  data  base  located  at 
either  a  local  and/or  AFLC  site.  There  is  a  further  implication  of  data  and  software  exchanges 
between  two  or  more  locations.  Data  networks  could  provide  some  support  to  all  of  these 
subelements  via  providing  easy  accesses  to  data  bases  and  an  expedient  communications  media 
for  exchanging  intelligence  information,  system  status,  and  software  algorithms. 

4.4. 1.2  Requirement  2;  Change  Analysis  and  Specification 

This  requirement  involves  an  examination  of  the  ECS  change  for  its  feasibility,  definition, 
design  and  a  proposal.  Primarily  the  envisioned  design  must  be  related  to  an  existent  baseline 
and  broken  into  work  packages.  Data  networks  could  provide  support  by  providing  a  repertoire 
of  software  tools,  configuration  management  assistance,  management  information,  documenta¬ 
tion  assistance,  and  access  to  common  and  unique  data  files.  This  appears  to  most  readily  apply 
at  a  local  network  level  because  of  the  high  degree  of  local  control  and  accessibility. 

4. 4. 1.3  Requirement  3:  Engineering  Development  and  Unit  Test 

This  requirement  develops  the  ECS  change  and  performs  engineering  tests.  Networking  can 
apply  primarily  at  a  local  level  to  provide  access  to  analysis  software,  tests,  and  development 
activities.  Command-wide  networks  offer  little  promise  except  where  the  desired  software  may 
exist  at  an  alternate  geographical  location. 

4.4. 1.4  Requirement  4:  System  Integration  and  Test 

This  requirement  reflects  a  testing  of  the  amended  ECS  to  ensure  the  previous  capabilities 
were  not  adversely  impacted  by  adding  the  ECS  change.  Both  the  original  and  the  updated 
baselines  are  often  checked  against  a  test  scenario,  the  performance  noted,  and  the  results 
published.  Networking  can  provide  significant  support  capability  to  all  of  these  activities  by 
maintaining  baseline  description  data,  change  description  data,  test  scenarios,  and  linking 
various  levels  of  data  bases. 
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4.4. 1 .5  Requirement  5:  Change  Documentation 

This  requirement  actually  accomplishes  baseline  documentation  revis:ons.  Networking  can 
anply  through:  interfacing  user  elements  to  baseline  description  contained  in  r.positories  and 
working  sites,  supplying  management  information,  ensuring  that  approval  of  the  revised 
documentation  is  aceomplisned,  and  ensuring  that  revised  data  is  properly  linked  to  the  appro¬ 
priate  data  bases. 

4.4. 1 .6  Requirement  6:  Certification  and  Distribution 

This  requirement  is  primarily  an  administrative  one,  however,  networking  can  easily  sup¬ 
port  tnis  type  of  requirement. 

4. 4. 1.7  Requirement  7:  Rapid  Reprogramming 


This  requirement  applies  to  all  ECS  categories  except  ATE.  It  further  indicates  that  routine 
changes  or  support  may  be  reprioritized  if  proper  urgency  exists  and  that  tools  may  need  to  be 
quit  :ly  available.  Additionally,  some  data  may  need  treatment  as  classified  data.  Networking  at 
local  levels  will  significantly  enhance  prioritization  of  tasks,  sharing  of  resources,  and  classified 
processing/storage . 

4. 4. 1.8  Requirement  8:  Respond  to  Frequent  Changes 

This  requirement  stems  from  a  rapid  accumulation  of  change  requests  which  exceeds  the 
reaction  or  development  time  for  the  changes.  A  block  change  approach  can  be  used  to  alleviate 
the  problem  and  thus  networking  can  readily  contribute  by:  providing  quick  access  to  a  general 
data  base,  configuration  control  of  baselines  and  the  block  changes,  quick  access  to  change 
tools,  ano  an  expedient  exchange  of  information. 

4.4. 1.9  Requirement  9:  Improved  Intelligence  Responsiveness 

This  requirement  indicates  direct  linkages  are  required  from  intelligence  data  sources  to 
ALC’s  so  that  accurate,  rapid  interpretation  of  the  data  may  be  applied  to  the  ECS  weapon 
system.  Networks  can  provide:  the  ready  access  required,  a  classified  data  handling  capability, 
automatic  routing  of  message  and  data  traffic,  a  commonly  accessible  data  base.  Local  and  long 
distance  networks  have  some  application. 

4.4.1.10  An  Improved  Documentation  System 

This  requirement  is  related  to  automating  documentation  to  a  practical  extent.  A  lai  te, 
easily  accessible  data  base  is  necessary  with  quick  transfer  of  data  to  user  points.  Certain  soft- 
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ware  programs  should  also  be  transferable  to  users  to  allow  added  documenting  capability.  Net¬ 
working  at  both  local  and  command  levels  can  significantly  aid  in  satisfying  this  requirement. 

4.4.1.11  Requirement  11:  Improved  Configuration  Management  System 

This  requirement  is  related  to  a  standardized  configuration  management  for  all  of  AFLC 
with  maximization  of  automation  capabilities.  A  large,  easily  accessible  data  base  is  necessary 
with  quick  transfer  of  large  amounts  of  data  to  user  locations.  Configuration  control  of  master 
software  can  be  accomplished  by  confining  data  base  update  capability  to  the  master  controller 
only.  Networks  can  significantly  assist  in  meeting  this  requirement. 

4.4.1.12  Requirement  12:  Improved  Management  Information  System 

This  requirement  encompasses  that  set  of  data  that  provides  status,  progress,  and/or 
accountability  information  to  all  management  levels.  The  data  must  be  kept  current  and  in  an 
easily  decipherable  format.  A  large  data  base  is  envisioned  that  minimizes  daily  or  periodic  up¬ 
date  efforts  by  worker  levels.  Networking  can  significantly  assist  in  meeting  this  requirement. 

4.4.1.13  Requirement  13:  Software  Support  Tools 

This  requirement  includes  software  routines,  algorithm,  and  models  to  enable  more  exped¬ 
ient  changes  and/or  development.  The  total  data  may  be  dispersed  to  several  geographic  loca¬ 
tions  or  at  one  large  data  base.  Networking  can  enable  ALC-to  ALC  transfer  of  these  tools  phis 
expedient  access  to  any  common  data  base. 

4.4.1.14  Requirement  14:  Software  Repository 

This  requirement  exists  to  ensure  that  copies  of  master  software  are  located  at  multiple 
geographical  locations.  The  software  dispersement  precludes  calamitous  results  to  a  develop¬ 
ment  or  support  program  should  the  master  be  inadvertently  destroyed.  Networking  car 
facilitate  a  dispersed  repository  with  the  capability  of  rapid  transfer  of  any  reeded  software 
ffom  network  nodes. 

4.4.1.15  Requirement  15:  Modular  Integration  Support  Facility  (ISF) 

This  requirement,  by  its  nature,  inherently  contains  a  local  network.  If  more  than  one 
modular  ISF  is  used,  then  a  long  distance  network  can  be  used  to  link  them  together. 

4.4.1.16  Requirement  16:  Skill  Concentrations 

This  requirement  indicates  some  coagulation  of  expertise,  manning,  hardware,  and/or  soft¬ 
ware  will  occur  at  the  various  ALC’s.  The  expedient  exchange  of  data  between  the  ALC’s  will 
necessitate  some  form  of  networking. 
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4.4.1.17  Requirement  1 7:  Improved  Training  System 

This  requirement  is  an  attempt  at  gaining  productivity  without  expanding  manning 
resources.  Productivity  is  to  be  gained  by  enhancing  individual  or  group  expertise  through  train¬ 
ing  efforts.  Networking  can  enable  extensive  and  expedient  data  exchanges  between  teachers  and 
pupils  or  between  data  bases  and  data  users. 

4.4. 1 . 1 8  Requirement  18:  Improved  Management  Communication 

This  requirement  includes  such  capabilities  as  teleconferencing,  electronic  mail,  and 
automatic  routing  of  data.  Primarily,  these  capabilities  can  assist  in  management  decision  mak¬ 
ing  plus  provide  a  more  cost  effe.tive  approach  to  group  meetings  than  air  or  ground  travel. 
Networking  can  accommodate  these  capabilities,  at  both  local  and  long  distance  levels. 

4.4.1.19  Requirement  19:  Other 

This  requirement  includes  considerations  for  modularity,  standard  equipments  where  prac¬ 
tical,  interoperability,  network  extendability,  etc.  Any  or  all  of  these  can  be  assisted  by  properly 
designed  networks. 

Table  4-8  indicates  a  list  of  the  network  task  requirements  concluded  from  examining  the  19 
ECS  support  requirements  in  view  of  the  relationship  of  the  long  range  support  objectives 
defined  by  Appendix  A.  From  the  table,  one  can  conclude  the  tasks  which  a  local  or  command¬ 
wide  network  will  be  required  to  accomplish  or  support.  These  tasks  are  relatable  througi.  the 
ECS  support  requirements  directly  to  the  overall  support  objectives  as  indicated  in  Table  4-8. 
Table  4-9  indicates  the  results  ot  consolidating  the  network  tasks  requirements  together. 

4.4.2  ECS  Support  Networks  Elements  and  Design  Alternatives 

Network  design  decisions  are  generally  based  on  network  performance  requirements, 
number  of  nodes  in  the  network,  the  method  of  nodal  interconnectivity,  operating  parameters, 
and  any  special  considerations  such  as  availability,  configurability,  and  network  security.  Once 
network  requirements  have  been  defined,  a  set  of  specifications  can  be  developed  which,  in  turn, 
are  used  to  design  the  network.  The  network  may  either  have  to  be  developed  from  scratch  or 
existing  communications  capabilities  may  be  used  to  form  the  backbone  or  starting  point  for  c. 
full  capability. 

The  following  sections  describe  the  key  elements  on  design  considerations  used  to  scope  the 
network  performance.  Parameters  discussed  are  network  capacity,  reliability,  responsiveness  in 
real  time,  architectural  software  and  hardware  layering,  teleconferencing  capabilities  and  secur¬ 
ity  features.  In  addition,  several  network  categories  and  network  components  are  described 
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Table  4-8.  List  of  Network  Requirements 


Support  j  Individual  Support  Requirement  Fclated 

Requi remvnt  s*  !  to  Network  Requirements 

I  ;  •  Large  data  base 

J  •  Expedient  communications  (intelligence, 

information,  system  status,  sct.ware.  : 

algorithms)  j 

Z  •  Repertoire  of  software  tools  \  | 

•  Configuration  management  .nfo.  J  ^ata  j 

|  •  Management  information  Base 

•  Unique  and  common  data  tiles  \  ( 

•  Documentation  assistance  * 

3  •  Software  analysis  tools  ] 

1  •  Test  software  i 

I  • 

4  !  •  Test  scenarios  j 

(  •  Baseline  data 

!  •  Change  data 

i  ) 

b  0  Repository  data 

•  Configuration  management  svp.tem 

•  Documentation  ussistiir.ee  j 

!  •  Data  base  revision  | 

6  •  Nodal  linkages  1 

1  •  Status  accounting  data 

7  •  Prioritization 

•  Class;fied  processing  j 

•  Software  tools  access  1 

8  •  General  data  base  I 

•  Configuration  management  * 

•  Software  tools  j 

0  Rapid  data  exchange 

9  !  •  Intelligence  data  exchange  ! 

1  •  Commonly  accessible  data  base  j 

i  •  Classified  processing 

|  •  Automatic  message  or  data  routing 

lU  •  Large  data  base 

•  Transferable  software  j 

•  Rapid  data  transfer 

11  •  Large  data  Last* 

•  Rapid  data  transfer 

1  •  Master  control  (restiicted  data  base  update)  j 

12  •  Large  data  base  I 

•  Easily  updated  and  accessed 

13  •  Software  tools 

•  Possibly  geographically  dispersed 

•  •  Rapid  copy  and  exchange  i 

I 

14  •  Large  data  base 

•  Control  of  masters 

•  Geographical  dispersement 

15  •  Modularity 

•  Data  bus 

16  I  •  Local.  ..ed  specialization 

j  •  Expedient  data  exchange 

17  •  Remote  instruction 

•  Expedient  data  exchange 

•  Large  block  data  exchanges 

18  •  Electronic  mail 

•  Teleconferencing 

•  Automatic  routing 

•  Large  data  base 

19  •  Modularity 

•  Standardization  ' 

•  Interoperability  ! 

•  Network  expansion  j 


Numbers  refer  to  individual  requirements  discussed  on  previous  pages. 
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Table  4-9.  Summary  of  Network  Task  Requirements 

Develop  a  readily  accessible,  large  data  base 

Provide  an  expedient  communications  link  between  nodes 

Provide  support  to  such  ECS  support  capabilities  as  configura¬ 
tion  management,  management  information  system,  automated 
documentation,  training,  system  engineering,  modular  ISF's 

Provide  classified  data  handling  capability 

Provide  prioritization  capability 

Support  activities  such  as  electronic  mail,  teleconferencing, 
automatic  routing 

Provide  gateway  linkage  to  local  networks 
Provide  modular  expandability 

Emphasize  standardization  and  commonality  where  practical 

Provide  common,  shared,  and  node -dedicated  data  storage 
capabilities 


including  an  overview  of  interrelationships  between  the  previously  discussed  major  elements. 
4.4.2. 1  Network  Capacity 

Each  of  the  19  ECS  support  requirements  summarized  in  Table  4-8  affect  network  data 
capacity  to  some  degree.  Network  capacity  is  defined  by  both  communication  data  exchange 
rates  and  total  storage.  Also,  capacity  is  a  function  of  memory/disk  size  and  communications 
bandwidth.  At  this  point,  the  purpose  is  not  to  develop  specific  capacity  figures  but  to  present 
an  approach  whereby  these  figures  may  be  derived. 

Figure  4-21  illustrates  the  procedures  to  be  followed  to  determine  network  capacity.  Step  1 
in  determining  necessary  capacity  is  to  define  the  tasks  to  be  accomplished  or  supported  by  the 
network.  Examination  of  the  AFLC  support  requirements  addressed  in  Section  4.4.1  indicates 
the  networks  must  accommodate  a  large  data  base  made  up  of  configuration  management, 
documentation,  software  tool  descriptions,  master  software,  management  information,  etc.  The 
requirements  further  indicate  many  rapid  data  transfers  are  likely  between  various  network 
nodes.  These  task  related  parameters  must  be  determined  prior  to  ascertaining  exact  network 
capacities.  The  level  of  data  base  distribution  must  be  determined  in  terms  of  one  or  more  loca¬ 
tions  and  the  management  information  system,  automated  documentation  system,  configura¬ 
tion  management  system,  training  system,  etc.  must  be  conceptualized  to  develop  a  top  level 
design. 

Step  2  in  determining  the  network  capacities  is  to  establish  the  communication  interface 
capabilities.  Beyond  the  basics  of  single  or  stream  message  transmission  to  support  the  task 
requirements,  the  communication  mechanism  may  vary  depending  on  implementation  scheme. 
Because  these  choices  affect  the  characteristics  of  the  user  interfaces  and  the  structure  and 
design  of  the  network  itseif,  there  is  an  iteration  and  reiteration  necessary  between  the  choices 
and  the  target  network  tasks  before  specific  capacity  is  determined.  The  key  characteristics 
determining  the  optimal  communications  scheme  are  based  on  answers  to  the  following 
tradeoffs. 

1.  Error  Control.  Does  the  communication  mechanism  detect  errors,  cor¬ 
rect  errors,  notify  the  user  of  errors,  or  does  it  pass  data  with  undetected 
bit  errors?  Does  it  deliver  duplicate  messages  or  does  it  lose  messages?  It 
appears  that  for  most  AFLC  usages,  a  user  notification  of  errors  detected 
plus  the  message  transmission  would  be  adequate.  Another  request  could 
be  used  to  retransmit  until  a  correct  transmission  is  received. 

2.  Addressing.  How  is  the  destination  of  the  message  or  virtual  circuit 
addressed?  Is  addressing  only  to  a  single  address,  a  group  address,  or  is  a 
complete  broadcast  possible?  Single  addressing  will  suffice  for  any 
AFLC  or  ALC  inquiries  to  one  other  node  and  for  the  responding 
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answer.  Certain  tasks  such  as  configuration  management,  management 
information,  etc.  may  require  group  addressing.  Procedural  changes  or 
administrative  data  may  require  a  complete  broadcast  addressing 
scheme. 

3.  Data  Flow  and  Control.  Can  data  be  sent  simultaneously  in  both  direc¬ 
tions?  Is  a  flow-rate  technique  available?  Does  the  communication  chan¬ 
nel  provide  a  synchronization  mechanism  whereby  the  communicating 
users  can  identify  a  common  time  or  state?  AFLC  support  requirements 
do  not  appear  to  require  two-way  data  How,  however,  certain  uses  of 
group  addressing  appear  to  require  simultaneous  flow  from  a  transmit¬ 
ting  node  to  several  receiving  nodes. 

4.  Priority.  Are  there  any  options  for  priority  service,  multiple  levels  of 
priority,  and/or  preemption?  Rapid  reprogramming  support  implies  use 
of  some  sort  of  priority  scheme.  The  possibilities  range  all  the  way  from 
simply  revising  the  queue  of  requests  to  actual  message  interruption  with 
recognition  of  the  point  where  interrupted  to  allow  continuation  of  the 
original  tasks  after  the  priority  task  is  completed. 

5.  Security.  Does  the  communication  service  offer  any  security  mechanisms 
such  as  data  encryption  or  password  validation?  The  requirement  for 
increased  focus  on  intelligence  data  indicates  that  networking,  in  some 
manner,  will  likely  be  required  to  support  encrypted  data.  Current  intelli¬ 
gence  data  networks  used  by  FTD,  D1A,  etc.  use  encryption  devices. 

AFLC  can  justify  itself  as  a  user  and  thus  be  included  as  an  add-on  to 
one  or  more  of  the  existing  networks.  For  disseminating  intelligence  data 
among  AFLC  nodes,  encryption  devices  will  be  necessary  at  the  appro¬ 
priate  nodes  and  exchange  rates  will  likely  be  affected. 

6.  Delivery  Guarantees.  Does  the  mechanism  guarantee  delivery  of  mes¬ 
sages?  Can  the  sender  obtain  a  receipt  of  delivery  or  a  notification  of 
failure  or  inability  to  deliver  a  message?  This  is  a  similar  consideration 
for  error  control  except  it  is  more  oriented  toward  the  transmitting  side 
of  a  message  exchange.  The  concept  used  to  alleviate  this  problem  could 
impact  data  exchange  rates. 

7.  Topology.  (Topology  defines  the  specific  nodal  interconnectivity, 
i.e.,  ring,  star,  etc.)  Are  there  any  restrictions  based  on  location  or 
topology?  Who  is  addressable  from  a  particular  user?  Can  users  on 
nonadjacent  nodes  communicate  via  the  mechanism?  The  topology  of 
the  network  is  an  important  factor  to  consider  in  the  design  of  the  AFLC 
network  architectural  structure  as  well  as  the  placement  of  the  data  base 
and  processing  functions.  The  amount  of  centralization  or  distribution 
relates  to  the  efficiency  of  network  operation  and  control.  This  intercon¬ 
nectivity  determines  where  any  switching  nodes  or  routing  functions  are 
incorporated  into  the  network. 

The  choice  of  options  at  the  communications  interface  level  is  obviously  dependent  on  the 
task  or  application  requirements  and  the  technology  from  which  the  communication  mechanism 
will  be  constructed.  A  general  purpose  design  must  take  into  account  a  wide  range  of  tasks  and 
examine  their  communication  requirements.  AFLC  local  networks  may  use  only  specialized  net- 
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works  dedicated  to  a  single  task  or  function.  However,  it  appears  a  cornmand-wide  network 
should  be  based  on  a  more  general  purpose  architecture. 

In  step  3  where  network  capacities  are  determined,  tasks  art  allocated  to  individual  nodes. 
The  task  distribution  consideration  includes  both  the  communications  interfaces  as  well  as  task 
requirements.  Furthermore,  there  is  a  need  to  solidify  the  topology  of  the  network.  Hence,  the 
combination  of  topology,  assigned  tasks  to  each  node,  and  communications  interfaces  between 
nodes  define  the  capacity  demands  on  channels  between  any  two  nodes  or  sets  of  nodes.  This 
combination  means  that  nodes  (or  ALC’s)  must  be  assigned  responsibilities  for  items  such  as 
configuration  management,  automated  documentation,  etc.  Also,  the  concept  of  data  exchange 
between  the  various  nodes  should  be  defined.  Once  the  data  exchange  concept  is  determined,  the 
topology  (nodal  interconnectivity)  can  be  defined. 

In  summary,  the  three  steps  to  determine  network  capacity  are;  definition  of  network  task 
requirements,  establishment  of  communication  interface  mechanisms,  and  assignment  of  tasks 
to  nodes.  These  steps  will  provide  a  preliminay  determination  of  capacity. 

4. 4. 2. 2  Network  Reliability 

Reliability  is  a  quality  of  networking  that  should  be  an  inherent  consideration  during  net¬ 
work  design  and  development.  This  implies  that  the  generalized  goals  of  reliability  are  known 
and  published  prior  to  the  design  phase.  Experience  has  proven  that  improved  reliability  is 
achieved  where  design  goals  were  established  priot  to  development  rather  than  where  reliability 
was  a  fallout  of  the  system  design  process. 

The  following  points  are  realistic  design  goals  in  terms  of  reliability. 

1.  Failure  of  any  particular  node  will  not  render  the  network  inoperative. 

2.  Optional  or  alternative  interconnection  paths  between  nodes  can  be 
established  and  ensured  if  the  primary  or  direct  path  is  inoperative. 

3.  Stored  data  will  be  preserved  in  spite  of  electical  failure. 

4.  Communication  must  occur  between  two  nodes  without  store-and- 
forward  functions  at  any  other  station  (only  for  circuit  switching). 

5.  Master  data  can  be  accessed  with  an  inquiry  but  cannot  be  changed 
except  via  an  approval/change  loop, 

Unless  these  design  goals  are  considered,  the  network  will  potentially  lack  adequate 
reliability.  Reliability  along  with  ease  of  use  and  cost  effectiveness  are  all  key  factors  in  acquir¬ 
ing  a  network  that  will  be  willingly  and  widely  used. 
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Real  time  data  operations  is  defined  as  activities  and/or  support  functions  which,  without 
any  significant  time  delays,  use  data  as  it  evolves  or  changes.  Examples  of  real  time  applications 
are  video  conferencing  and  high  density  graphics.  In  either  example  the  data  generated  at  one 
location  has  an  immediate  effect  upon  another  location  or  node.  It  is  apparent  that  this  kind  of 
data  must  be  transferred  reliably  and  accurately  or  such  capabilities  are  prone  to  be  of  limited 
value. 

Local  networks  promise  to  make  broad  use  of  real  time  data  operations.  The  modular  ISF 
discussed  in  Section  4.2  is  an  example  of  this  use. 

The  extent  of  intended  use  of  real  time  data  operations  (RTDO’s)  has  a  significant  effect 
upon  network  availability  for  other  activities.  For  example,  if  there  is  a  continuous  need  to  sup¬ 
port  R7D0  and  the  network  is  also  used  for  other  activities,  it  may  be  necessary  to  design  a  net¬ 
work  with  parallel  channels  to  allow  the  two  types  of  data  (real  time  and  nonreal  time)  to  flow. 
A  parallel  channel  network  will  be  much  more  expensive  to  design  and  implement  than  a  single 
channel.  Even  if  a  single  channel  design  is  used,  there  may  be  periods  of  operation  for  RTDO 
which  would  conflict  with  prioritization,  regular  data  base  updates,  etc.  This  tradeoff  must  be 
recognized  in  the  initial  design  or  the  network  may  degrade  in  terms  of  efficiency. 

4. 4. 2. 4  Network  Architecture  Layers  and  Protocols 

Computer  network  architecture  can  be  defined  in  terms  of  communications  protocols 
which  provide  a  specific  set  of  communication  services.  This  subsection  addresses  protocols  and 
network  aarchitecture. 

A  protocol  is  a  set  of  mutually  agreed  upon  conventions  for  handling  the  exchange  of  infor¬ 
mation  between  computing  elements.  These  elements  may  be  circuits,  modems,  terminals,  hosts, 
processes,  or  people.  Initially,  most  protocols  were  designed  to  be  application-specific  and  were 
structured  to  perform  all  network  operations  from  lowest  to  highest.  Most  recent  protocol 
designs  consist  of  a  hierarchical  multi'ayered  structure  with  implementation  details  of  each  layer 
transparent  to  all  other  layers  in  the  hierarchy.  This  aproach  provides  a  broad  (and  standard¬ 
ized)  applications  base.  Specifically,  the  multilayered  structure  provides  the  advantages  of: 
separation  of  functions,  segregation  of  responsibility  for  resource  management,  and  support  of 
evolutionary  change.  There  has  previously  been  considerable  deviation  in  methods  of  decom¬ 
posing  network  protocols;  however,  both  industry  and  standards  committees  are  focusing  onto 
the  same  basic  division  of  layers.  The  resulting  model  is  shown  in  Figure  4-22.  An  examination 


Figure  4-22.  Typical  Model  of  a  Protocol  Hierarchy 


of  the  model  reveals  that  there  is  substantial  overlap  between  the  various  types  of  protocols. 
This  has  prompted  the  International  Standards  Organization  (ISO)  to  discuss  and  adopt  stan¬ 
dards  based  upon  the  various  protocol  types.  As  uses  of  these  standards  become  more  common, 
refinements  will  be  made  to  them  until,  sometime  in  the  next  few  years,  the  various  interfaces 
within  a  network  can  be  more  efficiently  designed.  The  lowest  protocol  level  is  identified  as  the 
physical  interface  followed  by  node-to-node,  end-to-end,  host-to-host,  and  up  to  the  highest 
protocol  of  resource  sharing.  This  lowest  to  highest  ranking  will  be  referred  to  later  in  this  sec¬ 
tion. 

4. 4. 2. 5  Network  Architecture  Structure 

It  is  useful  to  address  why  network  architectures  have  become  so  important  in  considering 
the  type  of  network  required  for  AFLC  ECS  support.  Network  architectures  are  driven  primari¬ 
ly  by  changes  in  user  requirements  and  the  cost  of  computing  technology.  Before  network  ar¬ 
chitectures,  individual  applications  were  designed  with  unique  communication  interfaces.  This 
allowed  the  user  to  communicate  only  with  his  counterpart  at  the  other  end  of  the  network.  Any 
attempts  to  connect  to  different  I/O  devices  or  other  applications  were  met  with  difficult,  if  not 
impossible,  interface  and  communications  problems.  A  common  communication  interface  was 
needed.  (This  type  of  interface  is  recommended  for  AFLC  ase.)  Even  though  the  answer  was 
apparent,  the  specific  parameters  defining  such  an  interface  were  vague;  each  application  1  ad 
differing  requirements,  communication  was  desired  among  heterogeneous  computers,  and  dif¬ 
ferent  communication  technologies  were  used  to  connect  systems  together.  Additionally,  rapid 
changes  were  occurring  in  relative  costs  of  computing  and  communications.  Computing  costs 
were,  and  still  are,  declining  rapidly,  while  the  costs  of  communications  were  decreasing  very 
slowly.  Instead  of  computers  being  the  dominant  cost  of  a  computing  system,  it  is  now  the  com¬ 
munications.  This  implies  that  more  attention  must  be  paid  to  communications,  even  at  the 
added  impact  to  computing,  if  a  cost  effective  network  is  to  be  developed.  The  three  fac¬ 
tors— the  desire  for  common  communication  mechanism,  the  development  of  standard  inter¬ 
faces,  and  the  sharing  of  communication  equipment-were  the  driving  forces  that  led  to  advances 
in  computer  network  architectures. 

Just  as  in  the  design  of  large  application  systems  and  operating  systems,  current  network 
design  philosophy  is  based  upon  the  concept  of  modularity  and  hierarchical  layered  structuring. 
The  complex  network  design  problem  is  divided  into  smaller  manageable  pieces  or  modules. 
These  modules  are  chosen  for  easy  expandability.  That  is,  lower-layer  modules  create  a  founda¬ 
tion  upon  which  higher-level  modules  are  placed.  Each  layer  oi  level  in  the  structure  uses  the 
functions  provided  by  the  level  below  and  provides  new  or  additional  functions  to  the  next 
higher  levels. 
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Structuring  systems  in  this  way  has  a  number  of  advantages.  First,  it  results  in  a  simple, 
well-structured  design.  The  interfaces  between  layers  must  be  well-specified  and  documented. 
This  helps  create  and  enforce  standards  so  that  others  can  build  to  these  interfaces  and  com¬ 
municate  through  such  mechanisms.  Layered  structures  also  provide  the  flexibility  to  replace 
layer  modules  with  equivalent  ones  without  affecting  other  layers  in  the  structure  simply  by 
making  the  replacement  layer  compatible  with  the  established  interfaces.  Figure  4-23  is  a 
simplified  example  of  a  layered  network  structure. 

Beyond  the  basic  structuring  concept,  the  design  issues  then  become:  how  to  decompose  the 
functions  into  layers,  how  to  determine  the  interface  between  the  layers,  and  how  to  design  the 
architectural  structure  to  accomplish  user  requirements  and  stay  within  state-of-the-art 
technology. 

As  indicated  earlier,  this  is  an  iterative  process  and  the  initial  functional  decomposition  may 
bear  little  resemblance  to  me  final  layered  structure.  Figure  4-24  is  included  as  an  example  of  an 
already  iterated  structure.  If  the  application  programs  represented  the  configuration  manage¬ 
ment,  training,  and  automated  documentation  systems,  each  application  would  have  to  inter¬ 
face  with  a  routing  algorithm.  The  routing  algorithm  would  ensure  that  queries  and/or  data 
from  any  application  would  be  addressed  and  forwarded  to  the  proper  node.  The  security  func¬ 
tion  is  an  algorithm  interfaced  to  the  routing  algorithm  which  assures  protection  of  sensitive 
data.  A  data  base  management  system  could  make  up  the  intermediary  layer  between  security 
and  the  physical  device,  such  as  a  disk  stroage.  This  is  only  given  as  an  example  and  either  the 
applications  or  functional  layers  could  be  something  else.  Note  that  each  layer  must  interface 
upward  or  downward  and,  therefore,  a  protocol  must  be  established  to  span  each  interface. 
With  that  in  mind,  the  following  discussion  on  protocols  is  offered. 

4.4. 2. 6  Protocols 

A  protocol  is  the  set  of  message  formats  and  exchange  rules  that  the  layers  use  for  control 
and  synchronization  of  their  communication  functions.  The  functions  performed  by  a  layer  are 
reflected  in  the  interfaces  to  that  layer.  Each  layer  is  concerned  with  its  own  function  plus  the 
interface  to  either  an  upward  and/or  downward  layer.  The  following  are  protocol  elements  com¬ 
mon  to  protocols  at  all  levels. 

1.  Addressing.  The  specification  or  representation  of  the  name  of  the 
source  and  the  destination  of  information. 

2.  Error  Control.  The  detection  and  recovery  from  errors  introduced  by  the 
lower-level  functions. 

3.  Flow  Control.  The  management  of  the  flow  of  information  from  the 
source  to  the  destination. 
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Figure  4-23.  Layered  Network  Structure 
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4.  Synchronization.  The  control  and/or  knowledge  of  the  state  of  each 
layer  to  provide  a  consistent  state  and  avoid  any  deadlock  conditions. 

In  addition  to  these  elements,  specific  protocols  may  have  others,  depending  on  the  par¬ 
ticular  functions  they  perform.  Some  of  these  are: 

5.  Circuit  Management.  The  connection  and  disconnection  of  message 
paths  or  circuits. 

6.  Sequencing.  The  management  of  an  ordered  sequential  flow  of 
information. 

7.  Message  Management .  The  segmenting  and  reassembly  of  messages  and 
the  management  of  buffers. 

8.  Priority.  Providing  differing  grades  of  service  through  the  communi¬ 
cation  mechanism. 

9.  Switching  or  Routing.  The  selection  of  a  path  from  source  to  destination. 

10.  Security.  Providing  secure  communications. 

1 1.  Accounting.  Accounting  for  the  use  of  network  resources. 

12.  Information  Representation.  The  manage. ..ent  of  the  format,  code  set 
size,  etc.  of  any  information  transferred  through  the  communication 
mechanism. 

At  each  level  in  the  layered  structure  the  requirements  of  the  communication  mechanism 
must  be  examined  with  respect  to  each  protocol  element.  Their  design  will  include  decisions  on 
whether  functions  should  be  completely  localized  or  distributed  across  several  nodes,  whether 
resources  are  statically  or  dynamically  allocated,  and  whether  the  topology  of  the  network  war¬ 
rants  specific  considerations.  Protocols  are  then  designed  accordingly. 

4.4.2. 7  Further  Design  Considerations 

The  two  additional  considerations  addressed  in  this  section  are  teleconferencing  and 
security.  Since  each  of  these  areas  is  currently  under  intense  scrutiny  in  the  DOD  networking 
community,  a  discussion  is  offered  here  to  acquaint  the  reader  with  them. 

4.4. 2. 7.1  Teleconferencing 

A  teleconference  is  an  organized  interaction,  through  a  communication  system  or  network, 
of  geographically  separated  members  of  a  group.  This  term  has  been  used  mainly  to  refer  to 
interactions  organized  or  presided  over  by  or  with  the  aid  of  programmed  computers.  In  some 
teleconferences,  the  members  of  the  group  participate  concurrently;  in  others,  each  member  logs 
in  when  it  is  convenient  for  him  to  do  so,  reviews  what  has  happened  in  his  absence,  makes  his 
contribution,  and  logs  out,  periiaps  returning  later  in  the  day  or  week. 


In  recent  years,  a  considerable  amount  of  experience  has  been  gained  with  computer- 
facilitated  teleconferencing^,  but  it  is  a  complex  and  subtle  art,  and  teleconference  programs 
still  have  a  significant  way  to  go  before  teleconferences  approach  the  naturalness  of  face-to-face 
interaction.  This  capability  is  projected  to  be  a  reality  prior  to  1990  and  thus  lends  itself  to  an 
AFLC  capability.  The  inefficiency  of  traveling  to  meetings,  the  inefficiency  of  letting  one  par¬ 
ticipant  take  up  the  time  of  other  participants  when  all  are  not  interested  in  his  comments,  and 
the  projected  higher  costs  of  travel  combine  to  make  teleconferencing  attractive  to  AFLC.  As  it 
is  further  perfected,  teleconferencing  will  be  an  extremely  useful,  important  technique. 

For  teleconferencing  to  displace  the  conventional  telephone  and/or  travel,  it  will  probably 
have  to  offer  speech,  writing,  drawing,  typing,  and  possibly  some  approximation  to  television, 
all  integrated  into  synergic  pattern  with  extensive  computer  support  and  facilitation.  Two  or 
more  communicators  will  then  be  able  to  control  displays  in  certain  areas  of  each  others  display 
screens  and  processes  in  certain  sectors  of  each  others  computers.  Each  communicator  will  be 
advised  by  his  own  programs  and  will  use  information  from  his  own  data  bases.  The  effect  will 
provide  each  user  with  a  wide  choice  of  media  for  each  component  of  his  communication  and 
with  a  very  fast  and  competent  supporting  staff.  The  use  for  AFLC  and  Air  Force  management 
information  exchanges,  ICWGs,  training,  etc.  is  apparent.  Planning  for  an  AFLC  network 
should  include  considerations  for  teleconferencing  as  this  evolving  technique  solidifies  into  a 
valid  capability. 

Although  electronic  mail  does  not  qualify  as  a  portion  of  teleconferencing,  it  is  a  very 
desirable  feature  enabled  by  networking  and  its  function  can  supplement  teleconferencing.  Elec- 
tonic  mail  provides  each  node  participant  the  option  of  sending  and  receiving  text  files  to  other 
network  nodes.  Users  regularly  “link”  to  each  other  for  assistance  or  simply  to  chat.  This 
feature  will  provide  an  invaluable  assistance  to  generating  “joint  user  prepared”  documenta¬ 
tion. 

4. 4. 2. 7. 2.  Network  Security 

The  three  basic  categories  of  security  that  should  be  covered  in  a  comprehensive  review  of 
the  topic  are 

1.  Physical  security, 

2.  Administrative  controls,  and 

3.  Computer  system  and  network  security  controls. 

t  “Teleconferencing  Systems  Expected  to  Reduce  Costs,”  Jay  C.  Lowndes,  Aviation  Week  and 
Space  T echnology,  June  8,  1981,  pp.  322-333. 
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Physical  security  is  comprised  of  those  measures  for  protecting  the  physical  assets  of  a 
system  and  related  facilities  against  environmental  hazards  or  deliberate  actions.  Facility  entry 
contols,  fire  protection  and  magnetic  media  storage  protection  are  examples  of  controls  com¬ 
monly  included  as  physical  security. 

Administrative  controls  ensure  that  a  system  is  used  correctly  and  comprise  the  proper  pro  ¬ 
cedures  for  collecting,  validating,  processing,  controlling,  and  distributing  data.  Included  under 
this  heading  are  data  processing  practices,  programming  practices,  classified  handling  pro¬ 
cedures,  assignment  of  responsibilities,  and  procedural  auditing. 

Computer  system  and  network  security  controls  are  the  techniques  available  in  the  hard¬ 
ware  and  software  of  a  computer  system  or  network,  for  controlling  the  processing  of  and  access 
to  data  and  other  assets.  A  complete  discussion  of  this  topic  should  include  accuracy  controls, 
personal  identification,  authorization,  operating  system  security,  encryption,  and  computer 
security  auditing. 

In  addition  to  adequate  physical,  personnel,  and  administrative  security,  data  in  the  com¬ 
puter  system  must  be  protected  against  unauthorized  disclosure,  modification,  restriction  or 
destruction  of  types  shown  in  Table  4-10.  Attacks  on  the  data  security  of  a  system  may  be  acci¬ 
dental  or  intertional.  More  accidental  attacks  are  reported;  however,  these  statistics  are  suspect 
because  no  estimates  are  available  on  the  intentional  (but  unreported)  attacks. 

The  protection  of  the  data  from  attack  through  the  instruction  streams  or  programmable 
portions  of  the  computer  and  communications  systems  which  comprise  a  network  is  provided  by 
the  data  security  features  of  the  network.  The  protection  provided  within  the  system  may  be 
accomplished  through  many  types  of  implementation,  but  functionally  it  must  include  at  least 
the  following:  a  method  for  identification  of  a  user  requesting  service;  authorization  techniques 
to  establish  a  security  relation  between  users  and  data  to  which  they  are  entitled;  controlled  ac¬ 
cess  methods  to  determine  whether  the  user  has  been  previously  authorized  to  access  the  data 
and  to  use  the  requested  services  or  programs;  and  a  surveillance  procedure  to  provide  a  record 
of  all  attempts  whether  authorized  or  not.  Assurance  is  also  required  that  the  system  itself  is  not 
lodified  by  the  user  to  subvert  the  protection  features.  In  current  systems,  this  integrity  of  the 
system  is  usually  provided  through  combined  hardware  and  software  facilities  provided  by  the 
computer  architecture  and  the  operating  system  design.  For  networks,  these  functions  are  also 
exactly  appropriate,  however,  individual  nodes  procedures  may  vary  slightly  form  other  nodes 
and  a  certain  amount  of  security  responsibility  dispersement  is  inherent  in  any  network  design. 

These  basic  functions  are  intended  to  deter,  prevent,  or  at  least  detect  all  of  the  attack  listed 
in  Table  4-10.  Complete  protection  or  absolute  security  cannot  be  achieved,  because  one  can 
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never  be  sure  that  some  newly-developed  method  of  attack  will  not  succeed  in  penetrating  the 
data  protection  mechanism  of  any  computer  system.  The  practical  objective  of  data  security 
must  be  to  make  penetration  so  difficult  and  costly  that  a  security  violator  is  deterred.  The 
minimum  desired  protection,  which  may  not  always  be  attainable,  is  that  any  attack  be  detected. 
A  serious  difficulty  is  that  a  successful  attack  may  leave  no  evidence  that  the  system  was  com¬ 
promised.  Unlike  the  theft  of  property,  the  theft  of  data  from  a  computer  system  leaves  the  data 
in  the  system  and  apparently  untouched. 

Before  a  user  is  permitted  to  transact  data  processing  functions  in  a  secure  system,  iden¬ 
tification  and  authorization  must  be  made  and  recorded  in  the  access  control  tables.  The  access 
control  tables,  often  called  the  security  profile,  when  subverted,  can  be  used  to  deny  authorized 
users  legitimate  access  to  data,  resources,  or  programs.  The  subverted  profile  can  be  used  by  a 
penetrator  to  give  himself  access  to  everything  in  the  computer  system.  To  prevent  subversion, 
the  programs  which  control  the  profile  must  be  accessible  only  to  the  security  office  whose 
members  are  responsible  for  control  of  access  to  the  organization’s  data. 

In  a  secure  system  with  a  security  profile,  a  user  must  first  sign  on  and  establish  his  identify. 
Upon  identifying  the  user,  the  system  has  available  (from  the  security  profile),  a  list  of  all 
devices,  data  files,  programs,  and  other  resources  to  which  the  user  has  been  authorized. 

After  sign  on  and  proper  identification,  the  authorized  user’s  program  is  given  access  to  the 
system  (storage  is  allocated,  system  control  tables  are  assigned,  etc.)  and  program  execution 
begins.  When  the  user  program  requests  status  information,  additional  system  resources,  in¬ 
put/output  devices,  or  access  to  data,  the  request  is  verified  through  the  data  security  functions. 
The  operating  system  matches  the  user’s  identification  against  his  security  profile  to  assure  pro¬ 
per  authorization.  Each  security  profile  indicates  security  level  and  the  type  of  data  access. 
Security  levels  permit  discriminating  among  devices  or  data  with  respect  to  sensitivity  or 
classification  of  the  data.  It  is  important  to  ensure  that  neither  programs  nor  users  declassify 
data  by  reading  it  at  a  high  security  level  and  outputting  it  at  a  low  security  level.  The  type  of 
access  allowed  determines  what  users  may  do  about  the  data:  some  may  read,  others  may  read 
and  '  rite,  others  may  delete  or  alter  data.  A  request  which  fails  a  security  check  may  cause  job 
termination  depending  upon  data  importance  and  the  established  procedures.  Surveillance  for 
maintenance  of  security  is  provided  by  recording  all  access  requests  for  subsequent  audit  by  the 
security  office. 

In  a  computer  network,  no  one  of  the  nodes  is  necessarily  predominant  in  terms  of  controll¬ 
ing  the  system  or  maintaining  security.  Each  node  can  contain  several  levels  of  data  storage  both 
directly  addressable  and  input/output  addressable.  Protection  of  this  multiplicity  of  data  intro- 


duces  a  real  challenge  to  a  data  security  system.  Special  problems  with  networking  stem  from  the 
remote  location  of  terminals,  increased  resource  sharing,  distributed  intelligence,  and/or 
distributed  data  bases.  The  dispersion  over  wide  geographic  areas  of  many  individuals  capable 
of  using  the  large  number  of  devices  to  access  computers  multiplies  the  danger  of  security  com¬ 
promise. 

As  ALFC  develops  a  network,  the  accessibility  and  sharing  of  data  is  obviously  desirable. 
Yet  security  precautions  and  procedures  tend  to  inhibit  both  accessibility  and  data  sharing.  This 
conflict  indicates  that  security  considerations  must  be  factored  into  early  network  design. 
Attaching  security  to  an  existent  “nonsecure”  network  will  likely  produce  an  inefficient  net¬ 
work. 

4.4. 2. 8  Network  Concepts 

An  AFLC  network  must  provide,  as  a  minimum,  three  basic  categories  of  capabilities:  each 
of  the  three  categories  of  networks  is  discussed  in  the  following  paragraphs. 

Resource  sharing  networks .  In  these  networks,  resources  on  one  computer  are  made 
available  to  or  shared  with  another  system.  The  resources  may  be  physical  devices 
such  as  line  printers  or  virtual  devices  such  as  disk  files.  Network  communications 
make  it  appear  as  if  the  remote  resources  are  locally  available.  Examples  of  resource 
sharing  activities  include  remote  file  access,  intercomputer  file  transfer,  distributed 
data  base  queries,  and  remote  use  of  printer  output  devices.  Communication  in  these 
networks  usually  occurs  between  a  program  executing  in  one  computer  and  an  in¬ 
put/output  resource  executing  in  another.  In  some  cases,  the  communication  involves 
a  stream  of  related  sequential  data  (such  as  a  file  transfer),  while  in  others,  short  in¬ 
dependent  messages  are  exchanged  (such  as  in  transaction-oriented  data  base  access). 

The  applicability  to  AFLC  use  is  in  the  area  of  shared  software,  common  data  base  in¬ 
formation,  configuration  management,  management  information  system,  and  other 
uses. 

Distributed  computation  networks.  In  these  systems,  cooperating  programs  or 
processes  executing  in  different  computers  in  the  network  communicate  and  exchange 
information  in  the  performance  of  an  overall  larger  task.  This  communication 
between  the  program  parts  is  analogous  to  the  communication  between  subroutines  or 
procedures  comprising  large  module'  programs.  In  networks,  messages  are  used  to 
exchange  information,  while  in  modula.  programs,  parameter  lists  or  shared  locations 
in  memory  are  used  for  this  purpose.  Examples  of  distributed  computation  networks 
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include  real-time  process  control  systems,  specialized  multiple  processor  systems  such 
as  a  data  base  computer,  and  parallel  processing  structures.  In  these  networks,  com¬ 
munication  occurs  between  programs  executing  in  distinct  systems.  The  communica¬ 
tions  may  consist  of  short  message  exchanges  or  of  transmitted  streams  of  data.  The 
applicability  to  AFLC  use  is  in  the  area  of  AISF's,  skill  center  concentrations,  intelli¬ 
gence  systems,  data  base  management  systems,  and  other  uses. 

Remote  communication  networks.  These  networks  connect  remote  interactive  ter¬ 
minals  and  batch  entry  /exit  stations  to  processing  capabilities.  They  usually  share  the 
communications  facilities  of  the  network  in  the  movement  of  information  to  and 
from  host  computers.  Interactive  terminals  usually  communicate  via  short  transaction 
like  message  sequences  while  batch  stations  transfer  sequential  message  streams.  The 
primary  uses  of  these  networks  to  AFLC  requirements  are  interactive  graphics 
systems,  interactive  training  system,  automated  testing  scenarios,  and  many  other 
uses. 

All  these  network  types  address  comminications  between  the  users;  e.g.,  resources  or  com¬ 
ponents,  residing  in  or  connected  to  the  network.  In  resource  sharing  network,  I/O  devices  com¬ 
municate  with  programs.  In  distributed  computation  networks,  programs  communicate  with 
each  other.  In  remote  communications  networks,  terminals  communicate  with  remotedly 
located  host  programs. 

As  can  be  seen  from  the  discussion  throughout  Section  4.4,  the  networking  capabilities  to 
improve  AFLC’s  ECS  support  are  complex  and  very  interwoven  with  the  network  tasks.  Several 
activities  have  been  indicated  which  require  AFLC  accomplishment  of  tradeoffs  and/or  answers 
prior  to  any  valid  attempts  at  designing  a  network .  Since  AFLC  task  requirements  address  needs 
which  span  all  the  categories  of  networks,  it  is  important  to  further  consider  some  other  areas 
which  also  impact  upon  specific  network  design.  Selection  of  one  or  more  of  these  areas  would, 
in  effect,  indicate  a  different  network  concept.  Thus  discussion  is  offered  in  the  following  pages 
concerning 

•  Network  processors, 

•  Circuit  switching  versus  packet  switching  communication  methods,  and 

•  Distributed  data  base  systems. 
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4. 4. 2. 9  Network  Processors 


Many  previous  attempts  at  networking  have  been  to  link  several  large  capacity,  general  pur¬ 
pose  computers  together.  Advances  in  computer  technology  and  diminishing  hardware  costs 
have  enabled  smaller  computers  to  segment  some  of  the  tasks  of  larger  machines  into 
manageable  tasks  to  be  accomplished  in  a  cost  effective  manner  by  the  smaller  machines.  The 
discussion  presented  here  is  to  indicate  the  applications  of  smaller  computers  to  some  network¬ 
ing  tasks.  This  consideration  presents  an  approach  at  acquiring  a  network  augmented  by  smaller 
machines  as  a  design  consideration  for  an  AFLC  network. 

Simple  multiplexing  is  implemented  as  an  economy  measure  to  increase  the  cost-effective 
utilization  of  communication  facilities.  More  complicated  algorithms  and  the  declining  cost  of 
programmable  processors  have  made  it  attractive  to  replace  hardwired  multiplexers  with 
minicomputers.  The  inherent  flexibility  of  these  computers  in  turn  made  other  functions  possi¬ 
ble.  For  example,  by  using  the  small  processors  as  programmable  interfaces  or  concentrators, 
the  dialogue  between  these  and  the  front  end  processor  may  be  more  complex.  This  can  improve 
the  network  efficiency  by  permitting  more  sophisticated  line  control  procedures  which  might 
enable  recovery  from  some  failure  situations  as  an  example.  Some  of  the  functions  previously 
performed  by  the  main  computer,  or  front  end  processor,  may  be  delegated  to  the  concentrator 
giving  a  more  immediate  response  to  the  terminal.  The  polling  of  local  lines,  or  resolution  of 
contending  terminals,  message  checking  and  formatting,  error  correction,  guidance  to 
operators,  and  similar  tasks  are  typical  of  those  conveniently  performed  by  a  concentrator  with 
a  reasonable  degree  of  p-ocessing  power. 

Front  End  Processors.  In  network  communication  many  of  the  tasks  performed  are 
relatively  simple,  but  highly  repetitive  and  can  make  considerable  demands  on  the 
time  of  a  computer.  It  often  proves  more  economic  to  perform  these  functions  by  a 
small  separate  computer  called  a  front  end  processor.  The  following  are  main  advan¬ 
tages  of  this  approach. 

1.  The  cost  of  hardware  to  attack  lines  is  often  less  with  a  small  computer, 
possibly  because  different  constructional  methods  are  used. 

2.  The  processing  load  removed  from  the  main  computer  will  considerably 
increase  the  power  available  for  computational  purposes. 

3.  It  becomes  possible  to  separate  the  complete  system  clearly  into  two  parts: 
the  main  processor  and  the  communications  network.  This  gives  increased 
flexibility  and  may  allow  one  part  to  be  enhanced  or  replaced  without 
affecting  the  other. 
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Concentrators.  When  synchronous  (fixed  time  slot)  time  division  multiplex  concepts 
are  extended  to  adaptive  asynchronous  behavior,  a  concentrator  is  required.  Concen 
tration  basically  involves  store-and-forward  operation  wherein  a  buffer  in  the  concen¬ 
trator  is  employed  to  accumulate  characters  coming  from  a  terminal  until  buf'er 
overflow  or  an  end  of  message  segment  signal  is  received.  The  accumulated  message  is 
then  transmitted  over  the  high  speed  network  circuit,  thus  taking  optional  advantage 
of  the  available  capacity.  Error  control  procedures  and  message  reassembly  may  be 
implemented  in  the  concentrator  as  well  as  terminal  speed  recognition  and  code  con¬ 
version.  The  concentrator  may  reformat  the  data  in  order  to  interface  the  different 
speeds  and  protocols  of  the  network  and  terminal  circuits. 

Switching  Processors.  Switching  computers  are  also  relevant  to  the  discussion  of 
communications  hardware.  In  order  for  a  user  to  establish  a  connection  with  n  par¬ 
ticular  computer,  he  can  dial  a  unique  number  to  make  that  connection  or  bv  request¬ 
ing  a  computer  to  dial  it  by  using  an  automatic  calling  unit.  If  a  user  is  to  dial  only  one 
number,  or  be  connected  to  one  leased  line  regardless  of  which  computer  he  wishes  to 
communicate  with,  then  a  switching  computer  must  be  employed  in  the  network 
architecture.  The  switching  computer  performs  the  store-and-forward  function,  that 
is,  a  message  is  received  en  route,  stored  only  until  the  proper  outgoing  lire  is 
available,  and  then  retransmitted.  Besides  the  inherent  flexibility  in  software  switch¬ 
ing,  the  store-and-forward  technology  allows  for  optimum  line  utilization,  since  inter¬ 
process  messages  can  be  mixed  with  interprocess  messages  involving  different  host 
computers  and  terminal  devices  on  the  network.  Also,  the  switching  computer  can 
perform  other  functions  such  as  concentrating  terminals  and  interfacing  to  service 
computers. 

4.4.2.10  Circuit  Switching  and  Packet  Switching 

The  term  “circuit”  is  usually  used  to  refer  to  a  point-to-point  physical  or  seemingly 
physical  path  which  can  support  continuous  communications  in  one  or  both  directions.  For  data 
transmission  purposes,  the  actual  transmission  may  employ  either  analog  or  digital  technique, 
and,  if  analog,  require  a  modern  (modulator-demodulator)  at  each  end  of  the  circuit.  Circuits 
are  supported  using  a  variety  of  media,  such  as  copper  wire;  microwave  links;  HF,  VHF,  and 
UHF  radio  links;  satellite  links;  and  two-way  cable  TV  installations.  The  design  consideration 
for  an  AFLC  network  is  not  initially  driven  by  the  physical  media  so  much  as  it  is  by  the  type  of 
messages  and  data  to  be  transmitted  over  the  media.  There  have  always  bee  i  two  fundamental 
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and  competing  approaches  to  message  exchages:  pre-allocation  and  dynamic-allocation  of 
transmission  bandwidth.  Simply  stated,  circuit  switching  relates  to  pre-allocated  transmission 
bandwidth  and  packet  switching  to  dynamic -allocation.  The  telephone,  telex,  and  TWX  net¬ 
works  are  circuit-switched  systems,  where  a  fixed  bandwidth  is  preallocated  for  the  duration  of  a 
call.  Most  radio  usage  also  involves  preallocation  of  the  spectrum.  Conversely,  message, 
telegraph,  and  mail  systems  have  historically  operated  by  dynamically  allocating  bandwidths  or 
space  after  a  message  is  received,  one  link  at  a  time,  never  attempting  to  schedule  bandwidth 
over  the  whole  source-to-destination  path.  Before  the  advent  of  computers,  dynamic-allocation 
systems  were  necessarily  limited  to  nonreal  time  communications,  since  many  manual  sorting 
and  routing  decisions  were  required  along  the  path  of  each  message.  However,  the  rapid  ad¬ 
vances  in  computer  technology  over  the  last  two  decades  have  not  only  removed  this  limitation 
but  have  even  made  feasible  dynamic-allocation  communications  systems  that  are  superior  to 
preailocation  systems  in  connect  time,  reliability,  economy,  and  flexibility.  This  newer  com¬ 
munications  technology,  called  “packet  switching"  divides  the  information  into  small  segments, 
or  packets,  which  move  through  the  network  in  a  manner  similar  to  the  handling  of  mail  but  at 
immensely  higher  speeds.  Economic  and  performance  advantages  over  circuit  switching  systems 
have  resulted  in  widespread  acceptance  of  packet  switching  for  low-speed  interactive  data  com¬ 
munications  networks. 

The  question  facing  AFLC  is  to'  choose  which  concept  of  switching  is  most  cost  effective 
and  desirable.  The  answer  to  this  question  is  deiivable  from  the  type  of  predominate  message 
traffic  expected  on  the  AFLC  networks.  A  packet -switched  network  only  allocates  bandwidth 
when  a  block  of  data  is  ready  to  be  sent,  and  only  enough  for  that  one  block  to  travel  over  one 
network  link  at  a  time.  Depending  on  the  nature  of  the  data  traffic  being  transferred,  the  packet¬ 
switching  approach  is  an  estimated  3  to  100  times  more  efficient  than  preallocation  techniques  in 
reducing  to  wastage  of  available  transmission  bandwidth  resources.  To  do  this,  packet  systems 
require  both  processing  power  and  buffer  storage  resources  at  each  switch  in  the  network  for 
each  packet  sen,.  The  resulting  economic  tradeoff  is  straightforward:  if  lines  are  cheap,  use  cir¬ 
cuit  switching;  if  computing  is  cheap,  use  packet  switching.  Circuit  switching  is  suitable  for 
relatively  long  message  trasmission  such  as  message  communication,  bulk  data  transmission  and 
digital  facsimile.  Packet  switching  is  suitable  for  short  message  transmission  such  as  inquiry 
response  and  terminal  communications. 

Previous  discussion  has  indicated  that,  currently,  communications  is  the  larger  costs  (versus 
computing)  in  a  network.  However,  if  existing  communication  lines  can  be  used,  then  perhaps 
there  is  a  closer  balance  between  the  costs  of  communications  versus  computers. 
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4.4.2.11  Distributed  Data  Bases 

Whenever  multiple  processing  devices  are  configured  in  an  information  network,  the 
possibility  of  a  distributed  data  base  exists.  In  the  broadest  sense,  the  data  stored  at  all  locations 
could  be  considered  to  form  a  distributed  data  base.  However,  for  practical  purposes,  a 
distributed  data  base  exists  only  when  the  data  elements  at  multiple  locations  are  interrelated,  or 
if  a  process  (program  execution)  at  one  location  requires  access  to  data  stored  at  another  loca¬ 
tion. 

A  distributed  data  base  may  consist  of  a  single  cor  '  a  set  of  information,  divided  into 
increments  which  reside  at  multiple  locations.  This  fou.  .a  called  a  partitioned  data  base.  An 
AFLC  example  of  this  could  be  part  of  the  configuration  management  system  “unique”  to  each 
ALC  or  a  training  program  residing  partially  at  more  than  one  ALC. 

A  distributed  data  base  may  also  consist  of  a  set  of  information  all  or  selected  parts  of 
which  is  copied  at  two  or  more  locations.  This  form  is  called  a  replicated  data  base.  An  AFLC 
example  is  the  “common”  part  of  the  configuration  management  system  that  resides  at  each  of 
the  ALC’s. 

A  partitioned  data  base  exists  when  a  conceptual  data  is  separated  into  sections  and  spread 
across  multiple  computers.  “Conceptual”  is  used  because  in  general  a  sin.  ie  data  base  is  not 
created  and  then  partitioned;  instead,  the  data  base  is  designed  as  a  logical  entity  but  actually 
only  created  in  the  form  of  its  partitions.  The  separate  sections,  because  of  their  interrelation¬ 
ship,  logically  form  a  single  data  base.  Data  base  partitioning  often  follows  the  natural  distribu¬ 
tion  of  data  base  access  requirements.  It  is  important  in  a  multinode  network  to  not  partition  so 
that  a  single  node  (or  nodes)  is  overloaded  by  constant  accessing.  Another  distribution  of  the 
data  is  possible  which  will  allow  a  more  equitable  accessing  load.  Accessing  can  be  parallel  to  the 
organizational  hierarchy,  that  is  vertically  through  organizational  levels;  or  it  can  be  horizontal, 
from  one  peer  element  to  another.  Data  can  travel  down  the  hierarchy  or  across  the  hierarchy. 

AFLC  applications  for  a  network  indicate  that  both  partitioned  and  replicated  data  will  be 
present.  It  is  also  apparent  that  horizontal  and  vertical  accessing  will  be  used.  The  mixture  of 
using  these  four  terms  should  be  determinate  in  conjunction  with  the  other  early  design  con¬ 
siderations  for  and  AFLC  network.  Additional  to  the  desired  design  considerations  are  the  cost 
factor  of  a  distributed  system.  These  costs  are 

1.  Cost  of  computers  (equipment  cost), 

2.  Cost  of  data  bases  (software  cost), 
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3.  Cost  of  communication  lines, 

4.  Storage  cost  of  data  bases, 

5.  Storage  cost  of  programs, 

6.  Communication  cost  of  queries  and  updates  from  users  to  programs,  and 

7.  Communication  cost  of  queries  and  updates  from  programs  to  data 
bases. 


4.4.2.12  Summary  of  AFLC  Network  Design  Considerations 

The  totality  of  elements  affecting  the  design  for  an  AFLC  network  are  summarized  in 
Figure  4-25.  Although  the  “bubbles"  are  shown  as  individually  affecting  network  design,  there 
is  realistically  an  interdependency  between  the  bubbles  themselves.  In  other  words,  none  of  the 
elements  are  completely  independent  of  the  other  elements.  The  basic  steps  in  arriving  at  a  useful 
design  incorporating  all  these  elements  or  features,  are  discussed  in  the  following  section. 

4.4.3  ECS  Support  Networks  Design,  Development,  and  Integration 

This  section  contains  detailed  discussions  of  some  of  the  steps  to  be  taken  in  the  perfor¬ 
mance  of  subtasks  during  the  network  definition  phase.  A  more  comprehensive  summary  over¬ 
view  of  all  the  ECS  Support  Network  design,  development  and  integration  phases  is  provided  in 
Section  5.  The  intent  here  is  to  relate  individual  actions  to  key  issues  discussed  in  the  previous 
section.  These  “actions”  are  related  to  subtasks  as  defined  on  sumary  sheet  5.2.4,  Section  5  as 
shown  in  Table  4-11.  The  attempt  has  been  to  show  the  “vertical”  relationship  between 
“actions”  and  the  actual  subtasks  to  be  accomplished,  culminating  in  a  subtask  deliverable 
item.  Due  to  the  scope  of  the  project,  no  attempt  has  been  made  to  provide  a  detailed  descrip¬ 
tion  of  all  actions  but  rather  to  highlight  some  key  steps  in  order  to  provide  the  reader  with  a 
flavor  of  task  complexity. 


Needless  to  say  is  that  these  tasks  are  not  altogether  independent  of  each  other.  Also,  more 
than  one  iteration  through  each  step  may  be  required  due  to  their  interrelationship. 


Action  1.  Specify  tasks  to  be  accomplished  by  networks  or  to  be  supported  by  networks.  Effi¬ 
cient  use  of  any  capability  presupposes  that  the  capability  is  designed  to  accomplish  certain 
tasks.  Thus  the  tasks  are  defined  prior  to  designing  a  capability  to  accomplish  them.  Networking 
is  no  exception  to  this  and,  therefore,  any  efficient  network  will  have  been  designed  with  specific 
task  accomplishment  in  mind.  Section  4.4.1  of  this  document  addressed  network  requirements 
and  summarized  them  into  Table  4-9.  Additional  requirements  will  undoubtedly  emerge  prior  to 
the  design  activity.  The  additional  information  should  be  furnished  by  AFLC  to  further  define, 
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Figure  4-25.  AFLC  Network  Design  Considerations 


as  an  example,  the  specific  procdures,  methods,  and  formal  by  which  configuration  manage¬ 
ment  or  training  will  be  accomplished.  Thus,  a  better  understanding  is  needed  or  just  what  data 
will  be  contained  within  a  large  data  base;  the  type  of  DBMS  necessary  to  access,  change  or 
update  the  data  base;  and  the  data  to  be  exchanged  via  networks  to  provide  support  to  these 
capabilities.  It  is  apparent  that  the  totality  of  all  ECS  support  tasks  for  which  networks  will  pro¬ 
vide  some  support  will  define  the  network  requirements  and  thus  move  one  step  closer  to  defin¬ 
ing  an  efficient  network.  These  definitions  of  requirements  must  be  accomplished  prior  to  pro¬ 
ceeding  to  any  other  actions.  If  a  particular  capability,  i.e.,  and  automated  documentation 
system,  requires  a  study  effort  prior  to  final  definition,  then  consideration  for  the  study  results 
must  be  factored  into  any  network  definition  efforts. 

Action  2.  Determine  the  number  of  nodes.  Many  networks  are  not  indefinitely  extendable  to 
additional  nodes  without  degradation  to  the  network  system.  Those  networks  that  are  designed 
for  particular  applications,  such  as  AFLC’s,  are  perhaps  more  susceptible  than  other  networks 
designed  specifically  for  expansion  or  to  include  additional  nodes.  Although  some  allowance 
can  be  made  for  additional  nodes  to  be  added  to  a  network,  it  is  advisable  to  design  with  a 
specific  number  of  initial  nodes  plus  a  maximum  expandable  number.  For  examples  for  AFLC, 
begin  with  nodes  at  the  command  headquarters  plus  each  of  the  five  ALC’s  with  an  expansion 
factor  to  include  nc  more  than  5  additional  nodes.  With  this  target  in  mind,  the  network  can  be 
designed  for  11  nodes  and  optimized  for  efficient  operation.  Geographical  location  of  nodes  is 
also  important  so  that  a  communications  media  can  be  established  to  support  the  network  node 
data  exchanges.  Even  beyond  the  node  indentifications  and  locations  there  is  the  designation  of 
the  local  network  focal  point  (organization)  who  will  be  responsible  for  interfacing  each  node  to 
the  network. 

Action  3.  Allocate  tasks  to  nodes.  The  first  two  actions  have  identified  which  tasks  are  to  be 
accomplished  by  the  network  and  how  many  nodes  are  to  be  used.  This  action  simply  divides 
and  assigns  the  AFLC  support  tasks  to  specific  nodal  locations  thus  enabling  one  to  see  which 
data  exchanges  are  necessary  between  the  various  node  pairs.  Allocation  of  tasks  should  be  done 
with  the  thought  in  mind  of  which  nodes  will  be  the  primary  focal  point  for  individual  tasks  as 
well  as  which  nodes  are  the  users  of  that  task.  Overall,  the  task  allocations  should  be  structured 
so  that  no  single  node  is  overloaded  or  unnecessarily  burdened.  On  the  other  hand,  considera¬ 
tion  should  be  given  to  communications  path  loading  and  any  peculiarities  of  either  tasks  or 
communications  links.  This  action  is  primarily  an  administrative  one  for  AFLC,  and  its  comple¬ 
tion  can  amount  to  allocation  of  overall  responsibilities  to  the  ALC’s  for  various  ECS  support 
tasks  such  as  configuration  management. 
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Action  4,  Establish  internodal  data  exchanges.  Now  that  individual  tasxs  have  been  assigned  to 
all  nodes,  it  is  necessary  to  estimate  the  data  exchanges  between  all  node  pair  combinations.  This 
action  is  very  helpful  in  determining  communication  path  capacity  per  task  per  node  Dair  and, 
when  all  task  data  exchanges  are  combined,  overall  capacity  requirement  for  any  node  pair.  The 
results  will  help  provide  an  indication  of  the  topology  to  be  used  in  connecting  the  network 
althrough  other  subsequent  steps  will  also  influence  both  capacity  and  topology.  This  action  will 
require  AFLC  to  establish  a  policy  for  the  various  data  to  be  exchanged  between  node  pairs. 

Action  5.  Determine  extent  of  Real  Time  Data  Operations  (RTDO).  This  action  is  necessary  for 
accomplishment  at  this  time  because  several  subsequent  step  accomplishments  are  dependent 
upon  the  outcome  of  how  much  real  time  data  operation  is  required.  Section  4. 4. 2. 3  addresses 
this  consideration  and,  in  one  sense,  the  extent  of  RTDO  affects  the  networks  tasks  as  well.  If, 
for  example,  it  is  deemed  necessary  or  desirable  that  video  conferencing  will  be  used  by  AFLC  in 
the  1990’s  then  the  extent  of  RTDO  is  increased  so  the  network  must  accomplish  this  task.  The 
extent  of  RTDO  is  essentially  an  AFLC  management  decision  depending  upon  whether  or  not 
tasks  requiring  RTDO  are  to  be  implemented.  If  the  decision  is  yes,  then  the  network  design 
must  factor  this  into  consideration. 

Action  6.  Determine  Network  Implementation  Concept.  This  action  establishes  whether  or  not 
microprocessors  are  established  at  the  interface  of  each  node,  the  kind  of  switching  to  be  used, 
and  whether  existent  leased  lines  will  be  used,  etc.  In  view  of  having  answered  questions  embed¬ 
ded  within  the  first  five  steps,  the  determination  of  the  concept  to  implement  is  a  function  of 
cost-effectiveness  versus  what  is  necessary  to  implement  the  first  five  actions.  The  emphasis 
toward  more  resource  sharing,  distributed  computation,  data  base  distribution,  etc.  all  affect 
the  answer  to  this  ster 

Action  7.  Define  security  hardware  and  software.  Almost  all  data  in  the  future  will  likely  be 
sensitive  either  from  a  proprietary,  classified,  or  need-to-know  perspective.  This  fact  will  dictate 
that  more  and  more  encryption  (or  its  substitue)  will  be  used.  Even  the  security  of  the  data 
within  its  storage  media  will  be  safeguarded  against  intentional  or  inadvertent  alteration  or  com¬ 
promise.  Both  the  hardware  and  software  used  for  these  purposes  affect  network  design  and 
acquisition/development  costs.  It  is  necessary  that  the  approach  to  treating  sensitive  data 
include  consideration  for  procedures  also.  Subsection  4. 4. 2. 7. 7  addresses  several  considerations 
for  safeguarding  data  and  information.  AFLC  must  establish  the  policies  and  procedures  to  be 
used  for  network  security  thus  identifying  necessary  equipments  and  interfaces. 
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Action  8,  Establish  gateways  to  local  networks,  it  is  assumed  that  each  network  node  will 
interface  with  a  local  network.  The  interface  or  gateway  must  be  established  to  enable  data 
exchanges,  queries,  etc.  from  one  local  network  to  another.  If  the  local  gateways  are  standard¬ 
ized,  this  will  provide  a  more  efficient  network  (proven  by  the  National  Software  Works  experi¬ 
ments).  However,  each  and  every  local  network  may  not  accommodate  a  standardized  gateway. 
In  any  case,  the  gateways  must  be  established  because  they  affect  the  communications  path  from 
one  local  network  through  the  AFLC  network  to  another  local  network.  Internoda'  protocols 
cannot  be  established  until  the  gateways  are  established.  See  the  section  on  modular  ISF's  for 
more  details.  This  action  is  comprised  of  both  technical  and  management  considerations.  Its 
completion  is  necessary  to  enhance  network  efficiency. 

Action  9.  Define  network  maintenance  and  management  responsibilities.  Although  this  stop  is 
primarily  an  administrative  one,  its  completion  is  very  important  to  the  efficiency  and  results  of 
an  AFLC  network.  The  answer  to  this  question  indicates  where  network  status  data  and  proce¬ 
dures  are  focused  as  well  as  the  agency  responsible  for  fixing  a  network  problem.  Maintenance 
and  management  responsibilities  should  be  kept  in  mind  in  accomplishing  all  other  steps.  This 
action  amounts  to  establishing  an  office  of  primary  responsibility  for  network  maintenance  and 
operations  control. 

Action  10.  Determine  architectural  layers  (by  node).  Actions  completed  to  this  point  have  mixed 
technical  and  managerial  decision  making.  Action  10  is  the  first  of  several  steps  that  are  almost 
entirely  based  upon  technical  considerations.  For  certain  of  these  actions,  the  completion  may 
depend  upon  a  study  effort,  however,  the  actions  are  still  roughly  arranged  in  sequential  order. 
The  determination  of  the  architectrual  layers  for  each  and  every  node  is  primarily  assiciated  with 
the  expected  or  required  functional  accomplishment  of  the  node.  (Subsection  4. 4. 2. 5  addressed 
several  considerations  in  this  area.)  Nodal  architecture  directly  relate^  to  efficiency,  accuracy, 
ease  of  use,  and  reliability  of  each  node.  A  well-planned  architecture  will  allow  functional 
improvements  to  a  node  without  usurping  other  functions  assigned  or  accomplished  by  that 
node.  This  action  can  be  completed  only  after  in-depth  technical  considerations  of  the  various 
nodal  functions  such  as  would  be  accomplished  by  a  study  effort. 

Action  11.  Establish  ordering  of  architectural  layers  at  each  node.  This  action  is  another  purely 
technical  consideration  which  determines  the  lowest  to  highest  ordering  of  the  various  functions 
to  be  done  at  a  particular  node.  Coverage  of  this  subject  is  contained  in  Subsection  4. 4. 2. 5 
although  the  specific  ordering  is  relate  to  the  actual  functions  themselves.  As  an  example,  refer 
to  Figure  4-24  and  postulate  that  not  every  automated  documentation  task  would  be  affected  by 
a  routing  algorithm.  Then  the  functional  architecture  layer  (routing)  could  be  deleted  between 


the  security  function  and  the  automated  documentation  tasks  at  those  nodes  which  did  not 
require  routing.  There  will  be  literally  dozens  of  such  considerations  for  each  node,  so  an  in- 
depth  consideration  should  be  given  to  each  node  and  its  functional  tasks. 

Action  12.  Define  protocols  between  all  layers.  This  action  establishes  the  format  and  exchange 
rules  between  the  various  architectural  layers  at  a  node.  Again  this  is  a  technical  consideration 
which  affects  the  efficiency  and  reliability  of  each  network  node.  Completion  of  this  action  can 
only  effectively  be  done  by  the  network  designer. 

Action  13.  Define  internodal  protocols.  This  action  establishes  the  format  and  exchange  rules 
between  network  nodes.  Internodal  protocols  are  affected  by  gateways,  communications  media, 
node  processors,  node  tasks,  and  other  considerations.  These  protocols  can  also  be  envisioned 
to  communications  path  and  conditions.  Action  13  is  a  technical  consideration  which  affects 
efficiency,  reliability,  and  actual  capability  of  network  to  perform.  Although  this  is  primarily  a 
technically  based  action.  AFLC  should  formulate  any  standardization  policies  to  address  inter¬ 
nodal  protocols  for  current  and  future  use. 

Action  14.  Define  data  base  disribution.  This  action  establishes  the  extent  of  centralization  of  a 
data  base.  It  further  allocated  dedicated  portions  of  the  entire  network  data  to  individual  nodes 
for  control,  accessibility,  and  processing  reasons.  The  distinction  between  this  action  and  Action 
3  is  that  Action  3  is  based  upon  operational  rationale.  This  action  considers  additional  distribu¬ 
tion  based  upon  improving  the  network  for  technical  reasons  and  can  only  be  satisfactorily  com¬ 
pleted  by  the  network  designer  in  conjunction  with  the  DBMS. 

Action  15.  Define  processor  types.  If  the  processor  to  be  used  is  GFE,  this  action  should  have 
been  considered  earlier,  perhaps  as  Action  3.  The  difference  has  to  do  with  making  the  network 
conform  to  use  of  a  previously  defined  processor  type  as  opposed  to  establishing  the  network 
then  defining  processors  to  enable  the  network  to  function  as  established.  This  is  a  technical  step 
and  it  can  be  carried  only  to  the  extent  where  a  procesor  type  is  generally  addressed  or  to  a 
specific  processor  nomenclature.  An  answer  to  this  action  question  is  very  dependent  upon 
almost  every  previous  action. 

Action  16.  Consolidate  all  previous  actions  into  capacity  requirements. 

All  previous  actions  have  addressed:  what  the  network  is  to  accomplish,  how  it  is  to  accomplish 
it,  what  rules  goven  its  use,  what  equipment  is  necessary,  and  where  the  tasks  are  assigned.  The 
composite  of  all  these  interrelated  considerations  yields  an  answer  to  what  capacity  is  needed  for 
the  communications  media,  how  much  data  storage  is  necessary  and  where  the  storage  is 
located,  what  processing  is  necessary,  and  how  the  nodes  interface.  This  is  a  technical  action 
plus  a  possible  affect  on  the  desired  operational  capability  of  the  network.  Its  completion 
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depends  upon  a  joint  consideration  of  AFLC  and  the  network  designer. 

Action  17.  Reiterate  actions  until  tradeoffs  are  determined.  Certain  of  the  actions  are  very 
interrelated  such  that  completion  of  them  by  their  sequence  may  result  in  a  “less  than  desired” 
capability  for  one  or  more  functions.  It  is  a  good  idea  to  retrace  through  all  the  actions,  again  in 
sequence,  but  with  a  look  toward  the  final  result.  The  purpose  of  this  is  to  provide  a  more 
optimal  design.  This  action  is  primarily  a  technical  consideration  by  the  network  designer, 
however,  its  ramifications  may  require  operational  adjustments  which  are  controlled  by  AFLC 
policies,  i.e.,  standard  network  internodal  protocols. 

Action  18.  Prepare  a  network  system  specification.  All  questions  should  be  answered  to  enable 
a  quality  cut  at  preparing  a  system  specification  for  the  AFLC  network.  This  action  should  be 
primarily  an  administrative  one  since  previous  actions  should  have  rectified  or  solved  most  of 
the  technical  considerations  as  well  as  the  overall  policy  and  procedural  guidances. 

Action  19.  Prepare  a  request  for  proposal.  This  is  the  action  which  culminates  in  a  solicitation 
for  bids  to  develop  and  acquire  a  network  in  accordance  with  the  system  specification. 

The  previously  described  19  actions  lead  to  an  efficient  network  for  AFLC  use.  Completing 
these  actions  produces  a  network  system  specification  and  a  bid  package  by  which  to  contract 
for  development  of  the  network.  See  Section  5  for  deta’ls  of  how  these  actions  are  time-phased 
and  translate  to  resource  estimates  for  their  completion. 


5.  ECS  SUPPORT  CAPABILITIES  ACQUISITION 


The  use  of  an  organized  approach  essential  in  applying  the  technical  management  and 
engineering  disciplines  required  at  all  levels  for  the  total  Air  Force  Logistics  Command  ECS  sup¬ 
port  effort.  The  organized  framework  described  in  this  section  points  out  the  time-phased 
actions  required  to  attain  the  required  1990  ECS  support  capability.  The  first  and  probably  most 
difficult  task  is  the  commitment  to  a  disciplined  step-by-step  acquisition/development 
approach.  Secondly,  those  tasks  that  are  clearly  beyond  the  capability  of  existing  manpower  and 
facility  resources  or  outside  existing  or  lanned  areas  of  expertise  should  be  addressed  through 
system  engineering/integration  contractor  support.  Finally,  those  issues  that  are  clearly  beyond 
the  management  prerogatives  of  the  Air  Force  Logistics  Command  must  be  identified  and 
addressed  through  coordination  and  higher  management  approval.  A  guiding  philosophy  in  the 
planning  phase  is  the  careful  allocation  of  available  and  planned  resources  to  avoid  excessive 
concentration  upon  details  at  the  expense  of  understanding  and  management  of  the  acquisi¬ 
tion/development  effort.  The  dynamic  nature  of  the  development  process  for  a  weapon  system 
and  its  ECS  support  facility  coupled  with  the  complexity  encountered  during  the  introduction 
and  use  of  this  system  in  the  operational  environment  requires  the  full  attention  of  the  manage¬ 
ment  structure  of  the  Air  Force  Logistics  Command.  The  acquisition  and  operation  of  ECS  sup¬ 
port  facilities  is  engineering  intensive  and  often  requires  augmentation  in  the  form  of  technical 
assistance. 

Approach  to  Support  Capability  Acquisition 

Weapon  systems  containing  ECS  and  associated  support  systems  are  acquired  according  to 
public  laws.  Defense  Acquisition  Regulations  (DAR),  with  various  Department  of  Defense,  Air 
Force  and  subordinate  command  regulations,  policy,  and  guidance.  Collectively,  these  systems 
and  rules  are  massive,  complicated,  and  often  cumbersome  because  they  were  not  designed,  and 
are  not  maintained,  as  a  system.  In  spite  of  this,  a  central  theme  in  all  of  them  is  a  need  for 
management  attention  and  discipline. 

The  systems  approach  to  the  acquisition/ development  of  ECS  support  capability  offers  no 
magical  solution,  but  it  is  consistent  with  the  time  honored  acquisition/development  process, 
and  does  provide  a  means  to  intelligently  allocate  resources  where  they  are  most  needed,  partici¬ 
pate  in  the  weapon  and  support  system  development  process  to  the  degree  necessary  to  ensure  its 
manageability/supportability  and,  most  important  of  ail,  to  acquire  and  maintain  flexible 
weapon  and  ECS  support  systems  that  are  reliable,  accessible,  and  maintainable  at  reasonable 
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cost  throughout  their  life  cycle.  Figure  5-1  shows  an  overview  of  the  approach  to  implementa¬ 
tion  of  the  recommended  administrative  and  programmatic  initiatives  and  provides  a  framework 
for  subsequent  detail  for  acquiring  a  responsive  long  term  ECS  support  capability. 

Administrative  and  Programmatic  Initiatives 

The  initiatives  are  divided  into  two  groups.  The  first  group,  referred  to  as  administrative 
initiatives,  are  those  which  lend  themselves  to  implementation  with  little  initial  impact  on  or 
within  existing  resources.  Some  of  these  initiatives  will  most  likely  evolve  to  program  status 
depending  upon  policy  decisions  but  the  administrative  initiatives  are,  for  the  most  part,  a  col¬ 
lection  of  diverse  interrelated  activities  with  high  potential  for  both  near  and  long  term  benefits 
as  well  as  establishment  of  context  and  direction  for  other  longer  term  initiatives.  Although 
there  are  obvious  interrelationships  and  interdependencies  between  the  two  groups,  this  distinc¬ 
tion  is  made  because  policy  and  guidance  initiatives  are  clearly  in  the  Government’s  domain,  and 
therefore  are  presented  separately  in  the  form  of  recommendations  in  the  following  areas. 

•  Management  and  Engineering  Practices 

•  Acquisition  and  Support  Practices 


The  second  group,  called  programmatic  initiatives,  are  those  which  address  the  very  struc¬ 
ture  and  procedure  for  accomplishing  the  ECS  support  process.  Although  they  depend  upon 
policy  and  direction  for  implementation  they  are  primarily  longei  term  and  require  concentrated 
programs  with  considerable  resources  to  build  upon  or  augment  existing  capability  as  well  as 
acquire  new  capabilities.  Implementation  detail  in  the  form  of  activities,  schedules,  and 
resources  are  presented  for  each  of  the  following  programmatic  initiatives. 

•  Automation  and  Standardization  of  ECS  Support  Processes 

•  Modular  Extendable  Integration  Support  Facilities 

•  ECS  Readiness  Support 

•  ECS  Support  Networks 

5.1  ADMINISTRATIVE  INITIATIVES 


The  administrative  initiatives  which  encompass  management,  engineering,  acquisition,  and 
support  practices  are  discussed  in  detail  in  Volume  II  of  the  Phase  II  report  and  in  Section  3  of 
this  report.  As  discussed  in  the  Phase  11  report,  these  issues  were  selected  through  a  filtering  pro¬ 
cess  as  the  issues  with  the  most  prominent  impact  and  with  the  most  promise  of  resolution.  The 
same  process  was  applied  to  the  additional  ECS  support  issues  discussed  in  Section  3.  The 
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administrative  initiatives  and  corresponding  recommendations  are  presented  in  Tables  5-1 
through  5-8.  The  relationships  of  the  various  initiatives  are  shown  in  Table  5-9.  The  recommen¬ 
dations  are  focused  on  the  following  ECS  support  areas. 

•  Personnel  and  training 

•  Funding 

•  Configuration  management 

•  Organizational  structure 

•  Microprocessors  and  firmware 

•  ECS  support  facilities 

•  Multi-ECS  support  systems 

•  Product  and  data  quality  at  transition 

5.2  PROGRAMMATIC  INITIATIVES 

Modernization  of  AFLC  command-wide  ECS  support  capability  over  the  next  decade  is 
dependent  upon  implementation  of  tu-  previously  discussed  administrative  initiatives  combined 
with  implementation  of  specific  programs  over  a  period  of  time  to  augment  existing  capabilities 
and  acquire  new  capabilities.  The  implementation  detail  presented  in  the  following  sections  is 
supported  by  and  coupled  to  the  Phase  II  report  and  the  discussions  in  Section  4  of  this  report. 
Together,  they  provide  planners  and  implementoi  s  a  long  range  plan  for  support  of  the  five  ECS 
categories. 

Implementation  detail  for  each  of  the  four  programmatic  intiatives  follows  the  overall 
acquisition  approach  shown  previously  in  Figure  5-1  with  definite  phases,  activities,  and 
schedules  which  are  presented  in  the  form  of  activity  flows  and  task  sheets.  Each  initiative  is 
introduced  with  a  graphic  depiction  of  its  conceptual  evolution  followed  by  overview  and  sum¬ 
mary  task  sheets  and  individual  phase  or  activity  task  sheets  which  are  related  to  the  acquisition 
or  development  process.  In  those  cases  where  the  initiative  contains  several  elements,  separate 
summary  task  sheets  or  summary  and  individual  phase  task  sheets  are  provided.  In  addition, 
where  the  activities  are  closely  coupled  as  in  the  acquisition  of  local  and  command-wide  ECS 
support  networks,  the  overall  dependencies  are  graphically  displayed.  Specifically,  the  remain¬ 
ing  sections  are  formatted  as  follows. 


Table  5-1.  Administrative  Initiatives  Related  to 
Personnel  and  Training 

Administrative  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  ECS  support  personnel  and 
training. 

Recommendations 

•  Develop  an  optimum  approach  version  of  the  logic  paths 
sketched  for  the  AFLC  GLDT  in  AFLCR  400- XX. 

•  Develop  specific  guidance/AFLC  policy  regarding  the  con¬ 
solidation  of  resources  (including  cross-training)  across 
ALC's  and  ECS's. 

•  Develop  a  generic  breakout  of  functions  and  activities  required 
in  the  software  O&S  job  for  a  given  ECS  as  well  as  for  a 
multi- ECS  environment. 

•  Develop  a  step-by-step,  time-phased  trace  depicting  the 
manpower  acquisition  (authorization)  process. 

•  Conduct  a  study  to  evaluate  traditional  support  roles  and 
missions  of  the  various  AFLC  organizations  as  they  relate 
to  computer  resources. 

•  Develop  roles  and  missions  pertinent  to  AC,  MMR.MMC 
MMEC,  MMET,  MA-T,  and  management  organizations. 

•  Consider  the  matrix  management  concept  in  the  above 
effort. 

•  Provide  guidance  to  the  ALC's  regarding  organizational 
structure  in  the  MMEC  organization  and  definition  of 
interface  functions  within  other  organizations. 

•  Clarify  and  definitize  in  USAF  level  guidance  (i.  e.  ,  AFR 
800-  14),  the  roles  of  the  using  and  support  commands 
insofar  as  software  O&cS  are  concerned. 

•  Establish  a  recruiting  activity  within  each  ALC,  thus  reducing 
the  engineering  role  in  this  regard  to  one  of  conducting 
technical  interview  and  deciding  amongst  candidates. 

•  Take  steps  to  have  software  manpower  removed  from  the 
"additive"  category  and  placed  in  the  manpower  baseline 
with  other  O&M  functions. 
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Table  5-1.  Administrative  Initiatives  Related  to 
Personnel  and  Training  (Continued) 


Administrative  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  ECS  support  personnel  and 
training. 


Recommendations 

•  Continue  attempts  to  establish  special  categories  and  high 
grade  authorizations  for  software  engineers. 

•  Establish  OPR's  for  ECS  software  O&S  training  at  HQ 
AFLC/LOE  and  at  each  ALC. 

•  Encourage  rotation  of  key  personnel  across  ECS' s  (  and  even 
ALC's)  to  help  keep  these  invaluable  resources  challenged 
as  well  as  to  accelerate  the  training  process  for  the  more 
junior  employees. 

•  Develop  more  definitive  AFLC  career  incentives  and  pro¬ 
gression  paths  to  attract  and  retain  competent  ECS  personnel. 

•  Adjust  classification  and  qualification  standards  to 
meet  ECS  requirements. 

•  Develop  a  means  to  track  ECS  skilled  personnel. 

•  Develop  and  implement  a  career  management  program 

•  Develop  and  implement  SEI's  for  civil  service. 

•  Develop  and  communicate  a  career  progression  ladder. 

•  Provide  engineering  management  and  technical 
skills  career  paths. 

•  Make  assignments  within  the  career  path. 

•  Ensure  engineers  are  utilized  in  engineering  positions. 

•  Institute  a  more  structured  training  program  which  cycles 
available  software  and  hardware  engineers  through  a  set  of 
formal  courses  and  a  controlled  job  training  program. 

•  Develop  a  formal  training  program  targeted  to  continued 
education  for  ECS  engineers  including  identification  of 
specific  courses  to  be  studied. 
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1  ^ble  5-1.  Administrative  Initiatives  Related  to 
Personnel  and  Training  (Concluded) 


Administrative  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  ECS  support  personnel  and 
training. 


Recommendations 

•  Develop  training  alternatives  for  beginning  and  experienced 

engineers  in  the  following  areas: 

•  Expand  the  AFIT  School  of  Logistics  Management 
courses  to  include  a  specific  section  on  ECS  systems 
management. 

•  Develop  a  short  course  on  ECS  engineering  manage¬ 
ment  for  theteleteach  systems  and  follow -on  commu¬ 
nications  media  to  include  video  networks  and  video  disks. 

•  Develop  a  series  of  basic  computer  science  courses 
for  wide  area  use  on  video  networks  or  local  use  of 
video  disk  teaching  systems. 

•  Develop  a  basic  systems  engineering  course  for  wide 
area  use  on  video  networks  or  local  use  on  video  disk 
teaching  systems. 

•  Encourage  AFIT  EE  and  CS  students,  projected  for 
AFLC  assignments,  to  specialize  in  subjects  relating 
to  ECS  support. 

•  Where  economically  feasible,  use  off-the-shelf  video 
instruction  and  telecommunication  services  offered 
by  commercial  companies  or  public  utilities. 

•  Develop  a  comprehensive  instruction  and  training 
plan  for  ECS  support  personnel  which  complements 
the  career  ladder. 

•  Develop  communication  resource  centers  at  each  ALC.  j 


Table  5-2.  Administrative  Initiatives  Related  to  Funding 


Administrative  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  budgeting  and  funding  for  life 
cycle  support  of  ECS. 

Recommendations 

• 

Definitize  funding  sources  for  participation  in  life  cycle 

ECS  support  activities  required  by  AFR  800-14. 

• 

Establish  definitive  guidance  within  AFR  800-14  and  fundiiig 
lines  in  the  PMD's  to  route  facility  and  IV&rV  funds  to  AFLC 
agencies  to  establish  support  capabilities. 

• 

Provide  for  full  funding  to  accomplish  the  AFLC  assigned 
mission  within  EEIC  585. 

• 

With  full  funding  under  EEIC  583,  reduce  the  split  funding 
now  inherent  in  the  software  block  change  concept. 

• 

Support  the  Joint  Logistics  Commander's  (JLC)  efforts  to 
reduce  restrictions  to  multi-year  contracts  including 
incremental  funding. 

• 

Develop  a  comprehensive  set  of  funding  procedures  to  include 
any  of  the  above  alternatives  in  the  form  of  an  AFLC  regulation 
and  keep  it  current  rather  than  disseminating  direction  through 
memorandums,  messages,  and  letters. 
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Table  5-3.  Administrative  Initiatives  Related  to 
Configuration  Management 

Administrative  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  life  cycle  configuration 
management  of  ECS. 

Recommendations 

•  Review  the  suitability  of  the  Computer  Program  Identification 
Number  (CPIN)  system  for  controlling  baseline  documentation, 
particularly  for  computer  programs  employed  in  a  multi¬ 
version  environment  involving  more  than  a  single  ECS  and  a 
single  weapon  system. 

•  Review  the  Operational  Support  Configuration  Management 
Procedures  (O/S  CMP)  outline  recommended  in  AFLCR  800-21 
to  reorient  it  more  toward  specific,  detailed  procedures 
rather  than  toward  top  level  planning. 

•  Formulate  a  generic  set  of  software  change  activities  and 
asociated  operations  and  support  functions  which  are  applicable 
for  standardized  configuration  management  across  the  five 
ECS  categories. 

•  Re-examine  the  requirements  ^et  forth  in  AFLCR  800-21  and 
66-15  regarding  the  use  of  Material  Deficiency  Reports  (MDR's), 
Materiel  Improvement  Projects  (MIP's),  and  TCTO's  to  report, 
track,  and  release  ECS  software  changes. 

•  Re-evaluate  the  manpower  and  staffing  plans  for  each  ECS 
currently  entering  the  inventory  to  ensure  that  proper  CM 
resources  such  as  tools,  personnel,  equipment,  and  facilities 
are  programmed. 

•  Ensure  that  training  plans  adequately  address  configuration 
management  requirements. 
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Table  5-4.  Administrative  Initiatives  Related  to 
Organizational  Structure 

Administrative  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  organizing  for  efficiency  in 
the  conduct  of  tl  i  life  cycle  support  of  ECS. 


Recommendations 


Develop  a  generic  systems  engineering  methodology  similar 
to  a  systems  engineering  management  plan  (SEMP)  to  be  used 
as  a  program  model  for  all  organic  efforts. 

•  Perform  an  organic  study  to  define  existing  ALC  system 
engineering  practices  /  procedures. 

•  Develop  a  common  methodology  to  be  used  throughout 
AFLC. 

•  Publish  this  methodology  in  an  easy-to-understand 
generic  SEMP  as  a  guide  to  be  followed  for  all  organic 
engineering  efforts. 

•  Develop  a  plan  by  which  systems  engineering  expertise 
will  be  developed  or  acquired. 

Consolidate  software  and  hardware  engineering  personnel 
in  a  single  organization  at  each  ALC  to  facilitate  a  more 
economical/ responsive  system  engineering  relationship 
within  and  across  ALCs. 

•  Conduct  a  study  to  determine  the  most  efficient 
organizational  structure  to  maintain  system  engineering 
quality  at  the  ALCs. 

•  Reorganize  to  the  results  of  the  above  study. 

Establish  skill  centers  for  concentrated  specialities  across 
the  ALCs  to  better  accommodate  emerging  technologies  and 
to  heighten  the  advantages  afforded  through  a  matrix  structure. 

•  Investigate  the  applicability  of  skill  concentrations  in 
speciality  areas  (suggested  candidates  are  networks, 
standardization,  technology,  etc.  ) 

•  Select  appropriate  sites  for  individual  skill  concentrations. 

•  Develop  formal  plans  for  implementing  the  skill  centers 
and  supporting  facilities. 
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Table  5-4.  Administrative  Initiatives  Related  to 
Organizational  Structure  (Concluded) 

Administrative  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  organizing  for  efficiency  in 
the  conduct  of  the  life  cycle  support  of  ECS. 

Recommendations 

•  Replace  themanpower  evaluation  function  in  the  software  O&tS 
manpower  authorization  loop  by  establishing  a  manpower 
screening  function  within  HQ  AFLC/LOE  to  approve  ALC 
software  O&rS  ECR  requirements. 

•  Establish  in  HQ  AFLC/LOE  a  special  position  (e.g. ,  GS-14 
or  GS-15)  for  an  expert  in  ECS  O&S  who  has  first-hand 
experience  in  the  problems  confronted  by  ALC's. 

•  Establish  a  more  structured  communications  loop  between 
HQ  and  the  ALC's  through  inhouse  status /problem  reviews. 
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Table  5-5,  Administrative  Initiatives  Related  to 
Microprocessors  and  Firmwares 

Administrative  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  the  acquisition  and  life  cycle 
support  of  microprocessors  and  firmware. 

Recommendations 

•  Formulate  a  joint  AFSC/AFLC  regulation  concerning 
acquisition  and  support  of  microprocessors  and  firmware. 

•  Provide  support  for  the  development  of  an  Ada  language 
for  microprocessors. 

•  Provide  guidance  for  the  incorporation  of  microprocessor 
and  firmware  implications  into  the  logistics  planning  process. 

•  Establish  a  need  for  AFSC  to  provide  data  on  microprocessors 
and  firmware,  sparing  requirements,  storage  environments, 
shelf  life,  and  parts  agreements  during  the  acquisition 
process. 

•  Establish  well-equipped,  growth-oriented  support  facilities. 
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Table  5-6.  Administrative  Initiatives  Related  to 
ECS  Support  Facilities 

Administrative  initiatives  oriented  towards  acquisition  and  support 
practices  which  are  primarily  related  to  acquiring  and  operating  ECS 
support  facilities. 

Recommendations 

•  Develop  a  coordinated  set  of  AFLC/AFSC  guidelines  for 
establishing,  and  operating  post- deployment  software 
support  facilities. 

•  Establish  the  need  for  an  ECS  support  facility  co  ncept  and 
requirements  study  to  be  performed  during  the  conceptual/ 
validation  phases  of  each  major  program  where  embedded 
computer  systems  are  involved. 

•  Modify  AFR  800-14  and  other  appropriate  guidance  to  more 
clearly  identify  the  funding  responsibilities  associated  with 
post- deployment  software  support  facility  acquisition  and 
support. 

•  Develop  a  PMD/PMP/ILSP  checklist  which  can  be  used  by 
HQ  USAF,  AFLC,  AFALD,  and  field  agencies  participating  in 
ECS  acquisition  to  ensure  that  these  documents  properly 
address  support  facilities, 

•  Incorporate  ECS  support  facility  planning  and  funding  as 
part  of  the  DSARC  process. 

•  Establish  through  channels,  a  means  to  provide  sufficient 
pre-PMRT  manpower  and  funding  for  post- deployment 
posturing.  DT&E,  IOT&E  support,  etc. 

•  Treat  the  CRISP  as  a  USAF -wide  memorandum  of  agreement 
(MOA)  for  establishing  for  post-deployment  ECS  resources. 

•  Develop  an  expansion  of  the  CRISP  content  to  include  con¬ 
tingency  planning  for  ECR's  in  the  event  manpower,  funding, 
MCP's  inherent  in  the  primary  support  concept  are  delayed 
or  denied. 
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Auministratwe  initiatives  oriented  towards  management  and  engineering 
practices  which  are  primarily  related  to  developing  criteria  for  life 
cycle  support  of  multi- ECS  support  systems. 

Recommendations 

•  Conduct  a  study  of  closely- coupled  ECS  and  of  projected 
sensors  and  ECS  to  determine  if  criteria  can  be  established 
which  will  aid  in  establishing  ECS  assignments  and  whether 
the  actual  hardware  should  be  included  in  simulation  facilities 
for  avionics  integration,  operational  flight  program  develop¬ 
ment,  trainers,  electronics  warfare,  etc.  Factors  to  con¬ 
sider  are  the  types  and  timing  of  interfaces,  the  nature  of  the 
processing  on  the  signals,  the  amount  of  interrupt  processing, 
the  BIT  test  requirements,  standardization,  functions  of  the 
ECS,  and  traffic  flow. 

•  Develop  an  experiment  using  emulations  of  an  existing  ECS  that 
will  demonstrate  the  feasibility  of  using  emulations  for  multi¬ 
use  ECS.  Consideration  should  be  given  to  incorporating  the 
emulation  in  an  AISF  and  a  trainer  to  establish  whether  con¬ 
currency  is  possible  using  emulations.  The  impacts  of  timing 
discrepancies  between  the  emulation  and  the  actual  embedded 
computer  execution  should  be  explored  and  boundaries  of 
acceptable  deviations  established.  Life  cycle  costing  of  the 
two  options  (emulation  versus  ECS  u.»c)  should  be  derived  and 
compared  to  establish  costing  estimates. 

•  Initiate  a  series  of  studies  to  examine  the  architectural 
innovations /structure  that  will  promote  testability  and  sup- 
portability  of  ECS.  The  studies  should  formulate  a  baseline 
of  data  and  expertise  within  AFLC  that  would  enable  AFLC  to 
shape  standards  and  impact  developments  to  increase  test¬ 
ability  and  promotability.  Specific  areas  that  should  be 
examined  include:  interface  ports  to  be  used  for  test  tools  such 
as  programmable  GMAC;  the  input/output  structure  for  not  only 
the  MIL-STD  1553  bus  but  also  direct  memory  access  of  high 
frequency  or  continuous  data  streams,  software  language  develop¬ 
ment  for  ECS  and  support  systems,  life  cycle  cost  effects  of 
incorporating  the  support  features,  jtan  iardized  modules  for 
aircraft  or  sensor  modules  including  plug-in  microprocessors, 
and  modularity  innovations  in  hardware  and  software  th;.t  iso¬ 
lates  a  change  to  a  specific  section  of  the  ECS.  This  initiative 
would  require  some  research  and  development,  but  the  emphasis 
is  on  increasing  the  supportability  of  transitioned  ECS  by 
changing  ECS  design  concepts. 
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Table  5-8.  Administrative  Initiatives  Related  to  Product 
and  Data  Quality  at  Transition 

Administrative  initiatives  oriented  towards  acquisition  and  support 
practices  which  are  primarily  related  to  ECS  supportability  and  the 
quality  of  ECS  products  and  data  at  transition. 


Recommendations 

'  Update  the  minimum  set  of  data  requirements  listed  in  AFLCR 
800-21  to  include  a  system  specification  and  software  develop¬ 
ment/support  facility  description  documents. 

•  Develop  content  standards  and/or  guidance  for  documents  not 
covered  under  MIL- STD  490  and  MIL- STD  483. 

•  Eliminate,  through  discrimination  in  the  source  selection 
process  and  through  contractual  terms  in  the  production  phase, 
proprietary  software  which  is  either  integral  to  or  used  in 
support  of  a  USAF- maintained  ECS. 

•  Establish  joint  AFSC/AFLC  regulatory  guidance  that  requires 
AFLC  approval  prior  to  the  reprogramming  of  funds  ear¬ 
marked  for  AFLC  requirements  to  other  acquisition  areas. 

•  Continue  to  encourage  AFLC  participation  in  the  requirements 
definition  phase  of  the  acquisition  cycle  to  ensure  adequate 
resources  for  post- deployment  support  are  defined  from  the 
onset. 

•  Conduct  independent  verification  and  validation  of  emerging 
systems  by  the  eventual  support  organization. 

•  Develop  rationale  for  accomplishment  of  IV&V  within  AFLC. 

•  Develop  a  sound  IV&V  methodology  to  be  accomplished 
on  selected  programs. 

•  Acquire  AFTEC  and  USAF/  LE/RD  concurrence  on  the 
selected  methodology. 

•  Mount  a  campaign  to  have  the  concept  made  a  part  of 
AFR  800-14. 


•  Request  Air  Staff  funding  allowances  and  planning  for 
AFLC  to  conduct  of  IV&V  of  new  programs. 


Table  5-8.  Administrative  Initiatives  Related  to  Product 
and  Data  Quality  at  Transition  (Continued! 

Administrative  initiatives  oriented  towards  acquisition  and  support 
practices  which  are  primarily  related  to  ECS  supportability  and  the 
quality  of  ECS  prc  'ucts  and  data  at  transition. 

Recommendations 

•  Limit  system  proliferation  through  commonality  and 

planning  emphasis. 

•  Develop  a  viable  module  approach  to  systems 
architecture. 

•  Develop  an  approach  to  standard  interfaces. 

•  Gain  AFSC  concurrence  on  utilization  of  the  above 
approaches. 

•  Formalize  the  approaches  through  regulations 

•  Emphasize  design  for  testability. 

•  Initiate  a  team  effort  involving  the  systems  integrator, 
hardware  engineer,  test  engineer,  and  the  systems 
software  engineer. 

•  Extend  the  above  team  effort  to  be  compatible  with 
integrated  logistics  support  planning. 

•  Develop  maintenance  strategy  in  parallel  with  system 
design  concepts. 

I 

•  Specify  how  things  fail  as  well  as  how  they  work. 

•  Incorporate  test  disciplines  into  the  design  so  that 
system  architecture,  interfaces,  and  accessibility  are 
beneficially  influenced. 

•  Develop  a  set  of  standard  methodologies  for  incorporat¬ 
ing  testing  capability  into  systems  design 

•  Gain  AFSC  concurrence  with  the  above  methodology. 

•  Formalize  the  above  approach  in  AFLC/AFSC  regulations. 

•  Stress  verification  of  product  testability  as  a  part  of 
acceptance  testing. 
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Table  5-8.  Administrative  Initiatives  Related  to  Product 
and  Data  Quality  at  Transition  (Concluded) 

Administrative  initiatives  oriented  towards  acquisition  and  support 

practices  which  are  primarily  related  to  ECS  supportability  and  the 

quality  of  ECS  products  and  data  at  transition. 

Recommendations 

•  Stress  better  documentation. 

•  Establish  a  focal  point  for  documentation  at  HQ  AFLC. 

•  Revise  AFLCR  800-21  to  reflect  a  realistic  set  of 
"minimum  documentation". 

•  Insist,  through  AFALD,  CRWG,  and  other  interfaces, 
that  documentation  standards  are  met  by  acquisition 
agencies. 


- - . - - - 


5.2.1  Automation  and  Standarduation  of  ECS  Support  Processes 

•  Conceptual  evolution  (Figure  5-2) 

•  Overview  and  summary  task  sheet  (Figure  5-3) 

•  Individual  phase  task  sheets  (Figure  5-4  through  5-9) 

•  Summary  task  sheet  for  local  project  tool  development  (Figure  5-10) 

5.2.2  Modulai  Extendable  Integration  Support  facilities 

•  Conceptual  evolution  (Figure  5-11) 

•  Ov  view  and  summary  task  sheet  for  Work  Station  Module  (Figure 
5-i  *.) 

•  Individual  phase  task  sheets  for  Work  Station  Module  (Figures  5-13 
through  5-17) 

•  Summary  and  individual  phase  task  sheets  for  Simulation  Kernels 
(Figures  5-18  through  5-23) 

•  Summary  irvd  individual  phase  task  sheets  for  Reprogrammable  Com¬ 
puter  Monitor  and  Control  (Figures  5-24  through  5-30) 

•  Summary  task  sheet  for  Programmable  Interface  Unit  (Figure  5-31) 

5.2.3  ECS  Readiness  Support 

•  Conceptual  evolution  (Figure  5-32) 

•  Overview  and  summary  task  sheet  (Figure  5-33) 

•  Individual  activity  task  sheets  (Figures  5-34  through  5-44) 

5.2.4  ECS  Support  Networks 

•  Conceptual  evolution  (Figure  5-45) 

•  Overview  and  summary  task  sheet  for  Command-Wide  Network  (Figure 
5-46) 

•  Individual  phase  task  sheets  for  Command-Wide  Network  (Figures  5-47 
through  5-52) 

•  Task  interrelationships,  Command-Wide  and  Local  Networks  (Figure 
5-53) 

•  Summary  and  individual  phase  task  sheets  for  EISF/Local  Networks 
(Figures  5-54  through5-64) 

•  Summary  task  sheet  for  Data  Base  Machine  (Figure  5-65) 
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BfV|UOfAUT<^ATEO  SOFT»gARe  TOOLS  T°  AID  MANAOEMCNT  AMO  INCREASE  AUTOMATION  AND  STAN 
BTOJE^TOOlT f  *CIAfORT  PROCESSES.  OVERALL  TASK  ALSO  INCLUDES  DEVELOPMENT  OF  LOCAL 


MAJOR  ISSUES/PROiLIM  AREAS 

— 

THE  SIZE  OF  THE  TASK  IS  CLOSELY  RELATED  TO  SUPPORT  PROCESS  STANDARDIZATION  AND  HOW  MUCH 
MODIFICATION  EXISTING  VENDOR  TOOLS  NEED  TO  PROVIDE  REQUIRED  CAPABILITIES. 


TASX  APfROACH 


1.  ESTABLISH,  AS  FAR  AS  PRACTICAL.  STANDARDIZATION  OF  SOFTWARE  SUPPORT  PRACTICES. 

2.  DETERMINE  CONCEPTUAL  ARCHITECTURE  OF  SUPPORT  SYSTEM. 

3.  BASELINE  REQUIREMENTS  AND  INTERFACE  SPECIFICATIONS  AT  SDR. 

4.  PERFORM  PRELIMINARY  AND  DETAILED  DESIGN,  CONDUCT  PDR  AND  CDR. 

s.  fabricate,  integrate,  test,  hold  fca.  pca,  for. 

6.  PROVIDE  TRAINING.  USERS  GUIDES,  PLACE  IN  OPERATIONAL  USE. 

7.  COLLECT  deficiency  reports  for  future  enhancements. 


LEVEL  OF  EFFORT 

'  12  PERSON  YEARS  OF  EFFORT  SPREAD  OVER  A  4.5  YEAR  PERIOD.  TWO  PERSON  YEARS  WILL  BE  REQUIRED 
FOR  DEVELOPMENT  OF  LOCAL  PROJECT  TOOLS  FOR  A  TOTAL  OF  14  PERSON  YEARS. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND _ 

SENIOR  SOFTWARE  SYSTEMS  ENGINEERS/SYSTEM  PROGRAMMERS  WITH  6  TO  10  YEARS  OF  APPLICABLE 
EXPERIENCE 


TASK  INPUTS/INTERFACES 

f — - - - 

SOFTWARE  TOOLS  TIEO  CLOSELY  TO  LOCAL  AND  COMMAND-WIDE  NETWORKS,  ElSF  ARCHITECTURE, 
DATA  BASE  MANAGEMENT  SYSTEM,  AND  SECURITY  NEEDS. 


TASK  OE LIVER ABLES/KEV  MILESTONES 

1.  REQUIREMENTS  DEFINITION  ISRR) 

2.  REQUIREMENTS  VALIDATION  ISORI 

3.  SYSTEM  DESIGN  IPDH/C0R1 

4.  FABRICATE  AND  UNIT  TEST 

5.  INTEGRATION  AND  TEST  (FCA  PCA,  FOR) 

6.  OPERATIONAL  ANO  SUPPORT  DEMONSTRATION 
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SYSTEM/3C0MENT 

REQUIREMENTS 

DEFINITION 
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^  INPUT  FROM  RELATED  ACTIVITIES 


MANAGEMENT, 
ENGINEERING,  ACQUISITION, 
AND  SUPPORT  PRACTICES 

•  MANAGEMENT.  DIRECTION 

•  PLANNING 

•  POLICY 

•  GUIDANCE 

•  BUDGET 

•  RESOURCES 


MOOULAR  EXTENDABLE 
INTEGRATION 
SUPPORT  FACILITIES 

»  ARCHITECTURE 

•  SECURITY 

•  DATABASE 

•  SIMULATION 

•  COMMUNICATION 

•  LOCAL  NETWORK 


ECS  READINESS 
SUPPORT 


•  INTELLIGENCE 

•  SECURITY 

•  DATA  BASE 

•  PRIORITIES 

•  THREATS 

•  TRAINING 


ECS  SUPPORT 
NETWORKS 


•  PROTOCOLS 

•  SECURITY 

•  TRAFFIC 

•  NETWORK  CONTI 

•  PRIORITIES 

•  ARCHITECTURE 


MANAGEMENT  TOOLS 


SYSTEM/ 

SEGMENT 

REQUIREMENTS 

DEFINITION 


1  WR  -  ALC 
|  SM-  ALC 
|  SA  -  ALC 
I  00  -  ALC 
r  PC -ALC  . 

REQUIREMENTS 


MIS 

FUNCTIONAL 

REQUIREMENTS 


LOCAL  PROJECT  TOOLS 

I  LOCAL  TOOL 
J  (MICROPROCESSER 
I  SYSTEM)  SOFTWARE  " 
|  REQUIREMENTS 


CM  TOOL 

FUNCTIONAL 

REQUIREMENTS 


LOCAL  TOOL 

HARDWARE 

REQUIREMENTS 


SOFTWARE  CHANGE  TOOLS 


SOFTWARE  SUPPORT 
PROCESS  AND  TOOL 
STANDARDIZATION 
STUDY 


AUTOMATED 
TOOL  SECURITY 
REQUIREMENTS 


SOFT*/ 
HOST  INI 
AND  RE 
ANALYS 


PRODUCTS 


SOFTWARE  SUPPORT  PROCESS  STANDARDIZATION  REPORT 
SOFTWARE  CHANGE  TOOL  HOSTING  CONCEPT  REPORT 
SOFTWARE  DATA  SECURITY  REPORT  \ 

SOFTWARE  CHANGE  TOOL  SOFTWARE  FUNCTIONAL  REQUIREMENTS  \ 
LOCAL  PROJECT  REQUIRED  ANALYSIS  1 

DBMS,  MIS,  CM  SYSTEM  FUNCTIONAL  REQUIREMENTS  1 

’’igp  *.*e  5-4.  Automation  and  Standardization! 

System/ Segment  Requirement! | 
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PL  AN 

VENDOR  SURVEY 
OF  APPLICABLE 
PRQOUC n 


TRADEOFFS  ON  EACH 
TOOL:  BUILD  OR  BUY,, 
ENHANCE  VENDOR 
PRODUCT 


ICD'S  FOR 
TOOL  KERNELS 


PRELIMINARY 
AND  DETAILED 
DESIGN 


^  PRODUCTS 

•  VENDOR  SURVEY  REPORT 

•  ACQUISITION  STRATEGY  PLAN 

•  SPECIFICATIONS 

•  ICD'S 

•  MANAGEMENT  PLAN 

•  SUPPORT  PLAN 

Figure  5-5.  Automation  and  Standardization  o; 

System/Segment  Requirements  Vi 
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OPERATION  AND 
SUPPORT 


TASK  DESCRIPTION. 


AUTONATION  AND  STANDARDIZATION  Of  ECS  SUPPORT  PROCESSES 


PRELIMINARY 
AND  DETAILED 
DESIGN 


SUBTASK  ntsrBIPTIQN  system/segment  requirements  validation _ 

TASK  OBJECTIVES) 


DETERMINE  SPECIFIC  REQUIREMENTS  AND  INTERFACE  CRITERIA  FOR  AUTOMATED  STANDARDIZED 
SUPPORT  TOOLS. 


MAJOR  ISSUES/PROBLEM  AREAS 


REQUIREMENTS  VALIDATION  MUST  CONSIDER  SUPPORT  TO  ALL  FIVE  SOFTWARE  CATEGORIES  lATD,  ATE. 
C  E.  EW.  OPPI  PLUS  SECURITY  AND  DATA  BASE  MANAGEMENT  SYSTEM  REQUIREMENTS  OF  THE  EISF  AND 
BOTH  LOCAL  AND  COMMANDWIDE  NETWORKS. 


TASK  APPROACH 


INITIAL  MANAGEMENT  INFORMATION  SYSTEM  IMIS)  AND  SOFTWARE  SUPPORT  SYSTEM  CONFIGURATIONS 
WILL  BE  SELECTED  TO  ALLOW  EXPANSION  BASED  ON  USER  EXPERIENCE  WITH  SYSTEM,  NEED  TO  EXPAND 
TO  NEW  REPORT  FORMATS.  NEW  HOSTS  AND  TARGET  COMPUTERS.  COST  TRADEOFFS  ARE  REQUIRED  TO 
DETERMINE  OPTIMUM  HOSTING  APPROACH,  AND  THE  INITIAL  LANGUAGE  AND  TARGET  ECS  SUPPORTED. 
VENDOR  SURVEYS  OF  AVAILABLE  TOOLS  AND  THEIR  APPLICAP'LITY  TO  REQUIREMENTS  WILL  FORM  THE 
BASIS  FOR  BUILO.  BUY,  OR  ENHANCE  EXISTING  CAPABILITY  DECISIONS 


LEVEL  OF  EFFORT _ 

ABOUT  3  PERSON  YEARS  OF  EFFORT,  PRIMARILY  IN  DEFINING  DETAILED  TOOL  REQUIREMENTS  AND 
INTERFACES  BETWEEN  TOOL  FRAGMENTS  (FUNCTIONAL  BUILDING  BLOCKS) 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND _ 

SOFTWARE  ENGINEERS  WITH  5  TO  7  YEARS  EXPERIENCE  IN  THE  APPROPRIATE  SPECIALTIES  IMANAGE 
MENT  INFORMATION  SYSTEM,  DATA  BASE  MANAGEMENT  SYSTEM,  SOFTWARE  CHANGE  TOOLS) 


TASK  INPUTS/INTERFACES 

r - - - - - - —  - - - — - - — - - — ‘  ■  “ 

SECURITY  REQUIREMENT  VALIDATION  DEPENDS  ON  CONCEPTUAL  ARCHITECTURE  OF  EISF  AND  BOTH 
LOCAL  AND  COMMAND  WIDE  NETWORKS.  DATA  BASE  MANAGEMENT  SYSTEM  SPECIFICA  .  IONS 
ARE  RELATED  TO  NETWORK  INTERFACE  COMPUTER  SPECIFICATIONS. 


TASK  DELIVERABLES/KEY  MILESTONES 

•  " 

1.  FINALIZE  SYSTEM  REQUIREMENTS  SPECIFICATIONS 

3.  FINALIZE  ICD'S 

3  DBMS  HOST  SPECIFICATION 

*  FINAL  CI/CPCI  REQUIREMENTS 

5  VENDOR  SURVEY 

8.  BUILD/BUY/TRADEOFFS 

7.  ACQUISITION  PLAN 

8.  MANAGEMENT  AND  SUPPORT  PLAN 
B  SDR 


MONTH  I  1  )  3 1  3  I  A  I  S I 


nd  Standardization  of  ECS  Support  Processes 
ent  Requirements  Validation 
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}  PRODUCTS 

•  DESIGN  IMPLEMENTATION  PLAN 

•  RFP  PACKAGE 

•  VENDOR  PROPOSALS 

•  DESIGN  DOCUMENTS 

•  HARDWARE 

•  SOFTWARE 


Figure  5-6.  Automation  and  Standardization  of  ECS  Suppi 
Preliminary  and  Detailed  Design 
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TASK  PttrPIPTinu  AUTOMATION  AND  8T  AN  DAW  DILATION  Of  ICS  8UPPORT  WOCTWH 

BUST  ASK  ntHPPIPTIftHI  PRtLIMINARY  AND  DgTAILED  OHION _ 

TASK  OBJECTIVE(S) 


PERFORM  PRELIMINARY  AND DETAILEO  DEtlON  OF  SOFTWARE  CHANGE  TOOLS,  AND  MANAGEMENT  SUP¬ 
PORT  TOOLS. 


CONTINUE  COORDINATION  WITH  EISF  AND  NETWORK  AREAS  ON  SECURITY,  DATA  BASE  MANAGEMENT 
SYSTEM  REQUIREMENTS,  HARDWARE  SELECTION  DECISIONS. 


1.  ORGANISE  PROPOSAL  PREPARATION  AND  EVALUATION  TEAM. 
7.  WRIfE/CONTRACTFORRFP. 

3.  EVALUATE  VENDOR  PROPOSALS. 


4.  MONITOR  VENDOR  PRELIMINARY  AND  DETAILED  OESIGN. 
■  MANAGEMENT  TOOLS 

•  SOFTWARE  CHANGE  SUPPORT  TOOLS 

•  TOOL  HOST  HARDWARE  SELECTION. 


LEVEL  OF  EFFORT 


I  ABOUT  3  PERSON  YEARS  OF  EFFORT,  PRIMARILY  IN  SOFTWARE  DESIGN.  EFFORT  NEEDED  DEPENDS 
HEAVILY  ON  REQUIREMENTS  OF  INDIVIDUAL  SYSTEMS. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND _ 

SOFTWARE  SYSTEMS  ENGINEERS  WITH  8  TO  7  YEARS  OF  APPLICABLE  EXPERIENCE  IN  DATA  BASE  MAN¬ 
AGEMENT  SYSTEM,  MANAGEMENT  INFORMATION  SYSTEM,  SOFTWARE  SUPPORT  SYSTEMS. 


TASK  INPUTS/INTERFACES 

r  - 

NETWORK  AND  EISF  COMPUTER  HARDWARE  SELECTION  HAS  SIGNIFICANT  IMPACT  ON  SOFTWARE/ 
HARDWARE  INTERFACE  REQUIREMENTS.  MANAGEMENT  SYSTEMS  SHOULD  PLAN  TO  USE  EXISTING  DATA 
BASES. 


TASK  DELIVERABLES/KEY  MILESTONES 

--  .  — 

1.  DESIGN  IMPLIMENTATION  PLAN 

2.  ISSUE  RFP 

3.  PROPOSAL  EVALUATION 

4.  EQUIPMENT  SELECTION 
6.  SOFTWARE  DESIGN 

6.  PDR 

7.  CDR 
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t  PRODUCTS 

•  ASSEMBLED  HARDWARE 

•  CODED  SOFTWARE 

•  UNIT  TEST  PLANS 


Figure  5-7.  Automation  and  Standardization  o 
Fabricate/Code  and  Unit  Test 


}  PRODUCTS 

•  INTEGRATION  PLAN 

•  TEST  PLAN 

•  TEST  PROCEDURES 

•  SPECIAL  TEST  HARDWARE  AND  SOFTWARE 

•  TEST  REPORTS 

•  "RED-LINED"  DESIGN  DOCUMENTS 


Figure  5-8.  Automation  and  Standardization  of  1 
System  Integration  and  Test 


\ 


TASK  DESCRIPTION 


automation  and  stanqa_rqi2Ation  OP  ICS  SUPPORT  PROCESSES 


% 

OPERATION 

AND  SUPPORT 

K 


SUBTASK  QKsrpiPTinM  ayatau  iMteoftATiQN  and  tbt 


TASK  OBJECTIVE(S) 

INTEGRATION  AND  TEST  Of  CI/CPCI'S  INTO  MANAGEMENT  SUPPORT  SYSTEM  AND  SOFTWARE  CHANGE  SUP^ 
PORT  SYSTEM  i 


l _ J 

MAJOR  ISSUES/PROBLEM  AREAS 

INTEGRATION  OF  DATA  BASE  MANAGEMENT  SYSTEM.  MANAGEUEN'i  INFORMATION  SYSTEM.  AND  CONFIG  1 

ORATION  MANAGEMENT  SYSTEMS  WITH  EXISTING  DATA  BASES  MUST  BE  DONE  WITHOUT  INTERFERING 
WITH  OPERATION  OF  EXISTING  TOOLS.  I 

- _ ) 

TASK  APPROACH 

/ - - -  '  -v 

1.  WRITE  INTEGRATION  PLAN. 

2  WRITF  SYSTEM  TEST  PLAN  AND  PROCEDURES. 

INTETRATE  MANAGEMENT  SYSTEM  AND  SOFTWARE  CHANGE  TOOLS. 

4.  V'ERf-ORM  SYSTEM  TEST  ON  THE  TWO  SYSTEMS. 

5.  WRITE  TEST  REPORTS. 

6.  CORRECT  SYSTEM  DEFICIENCIES  DISCOVERED  DURING  TEST. 


7.  REDLliYE  DESIGN  DOCUMENTS  TO  '•AS-BUILT*1  CONFIGURATION. 

LEVEL  OF  EFFORT 

”  1.5  PERSON  YEARS.  APPROXIMATELY  HALF  OF  WHICH  IS  DEVOTED  TO  SYSTEM  INTEGRATION 

PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

SOFTWARE  SYSTEMS  ENGINEERS  AND  TEST  ENGINEERS /PROGRAMMERS  WITH  A  MINIMUM  OF  5  YEARS 
APPLICABLE  EXPERIENCE  ON  SIMILAR  SYSTEMS. 

TASK  INPUTS/INTERFACES 

EXISTING  DATA  BASES  MAY  NEED  TO  BE  CHANGED  IN  FORMAT  (CONVERSION  PROGRAMS)  TO  INTERFACE 
WITH  THE  NEW  DATA  BASE  MANAGEMENT  SYSTEM 

TASK  DEUVERABLES/KEY  MILESTONES  1964  1985 


1.  WRITE  INTEGRATION  PLAN 

2.  DEVELOP  SYSTEM  TEST  PLANS  AND  PROCEDURES 

3.  DEVELOP  SYSTEM  TEST  HARDWARE  AND  SOFTWARE 

4.  PERFORM  CI/CPCl  INTEGRATION  AND  TEST 
5  PERFORM  SYSTEM  TEST 

6.  FUNCTIONAL  CONFIGURATION  AUDIT  (FCA) 

7.  PHYSICAL  CONFIGURATION  AUDIT  (PCA) 

8.  FORMAL  QUALIFICATION  REVIEW  IFQR) 


MONTH 


A 


3  lils  161  7JJ19 


A 


A 


-A 


Itandardization  of  ECS  Support  Processes: 
m  and  Test 


5-33 


/> 

\  ^ 


o 


OPERATIC 

SUPPORT 


^  PRODUCTS 

•  " AS-BUILT"  DOCUMENTATION 

•  TRAINING  COURSE  MATERIALS 

•  USERS  GUIDES 

•  DEFICIENCY  REPORTS 


Figure  5-9.  Automation  and  Standardization  of  1 
Operation  and  Support 
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OPERATION  AND 
SUPPORT 


TASK  DESCRIPTION. 


AUTOMATION  t 


SUBTASK  DESCRIPTION  .  OPERATION  ANO  SUPPORT 
TASK  OBJECTIVES) 


ENSURE  THAT  THE  SOFTWARE  TOOL  SYSTEM  IS  FULLY  OPERATIONAL,  PROVIDE  USER  TRAINING.  AND 
COLLECT  USER  DEFICIENCY  REPORTS  FOR  CORRECTION  IN  MAINTENANCE  UPDATES. 


MAJOR  ISSUES/PROBS.CM  AREAS 


OPERATIONAL  USER  EXPERIENCE  WILL  PROVIDE  VALUABLE  INSIGHT  INTO  UPGRADE  REQUIREMENTS. 


TASK  APPROACH 

— . ■  —  -  - - - - —  ■ —  1  —  —  —  -■  — 

1.  PUBLISH  "AS-BUILT"  SYSTEM  DOCUMENTATION. 

2.  WRITE  USERS  GUIDES 

3  OEVELOP  TRAINING  COURSE. 

4.  ESTABLISH  SYSTEM  DOCUMENTATION  LIBRARYS. 

5.  PRESENT  TRAINING  COURSE  TO  SYSTEM  USERS. 

6.  COLLECT  OPERATIONAL  DEFICIENCY  REPORTS  FOR  MAINTENANCE/UPGRADE  ACTIONS 


EXPANDED  ECS 
SOFTWARE  SUPPORT 
TOOLS  CAPABILITIES 


LEVEL  OF  EFFORT 

s' - 

1.5  PERSON  YEARS  ARE  REOUIREO.  PRIMARILY  FOR  WRITING  USERS  GUIDES  AND  PROVIDING 
TRAINING 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

s -  —  "  1  -■  -  —  -  —  -  —  -- 

THE  ABOVE  TASKS  REQUIRE  SYSTEMS  SOFTWARE  ENGINEERS  AND  PROGRAMMERS  WITH  4  TO  6  YEARS  l 
EXPERIENCE. 


i  ASK  INPUTS/INTERFACES _ 

’  training  WILL  HAVE  TO  BE  PROVIDED  TO  ALL  FIVE  ALC'S.  SOME  OF  WHICH  MAY  HAVE  UNIQUE 
REQUIREMENTS. 


TASK  DELIVERABLES/KEY  MILESTONES 

- — —  ■  —  ■■  - - - * - - 

1  ESTABLISH  DOCUMENTATION  LIBRARY  INCLUDING 

PUBLICATION  of  final  design  documents 

2.  WRITE  USERS  GUIDES 

3.  OEVELOP  TRAINING  COURSE 

4.  PRESENT  TRAINING  COURSE  TO  USERS 

5.  COLLECT  OPERATIONAL  DEFICIENCY  REPORTS 
8.  OPERATIONAL  DEMONSTRATION 


MONTH  12  3  4  5  6  7  8  9 


Hid  Standardization  of  ECS  Support  Processes 
id  Support 


TASK  OFSCBIPTION _ AUTOMATION  AND  STANDARDIZATION  OF  ECS  SUPPORT  PROCESSES 

SUBTASK  DESCRIPTION  LOCAL  PROJECT  TOOL  DCVE  LOPMENT  SUMMARY  TASK  SHEET  ( 

TASK  OBJECTIVE(S) 

[  PROCURE  ANO  INSTALL  MICROCOMPUTER  SYSTEMS  IN  ENGINEERING  WORK  AREA  FOR  SPECIFIC  LOCAL 
i  PROJECTS  PROVIDE  MANAGEMENT  AND  ENGINEERING  SUPPORT  TOOLS  FOR  THESE  SYSTEMS. 


MAJOR  ISSUES/PROBLEM  AREAS 

SYSTEM  CONFIGURATION  IS  THE  MAJOR  ISSUE  (PROCESSER.  MEMORY.  MASS  STORAGE.  PRINTER.  PLOT¬ 
TERS  MODEMS)  SOFTWARE  CAPABILITY  (SOFTWARE  LANGUAGES  SUPPORTED.  MANAGEMENT  TOOLS.  ENGI¬ 
NEERING  TOOLS.  ETC  I  HARDWARE  AND  SOFTWARE  ARE  MOSTLY  OFF-THE-SHELF. 

TASK  APPROACH 

1  PERFORM  A  STUDY  TO  DETERMINE  CANDIDATE  SYSTEM  CAPABILITY  AND  CONFIGURATION. 

2  PERFORM  COST/BENEFIT  TRADEOFFS  ON  SYSTEM  HARDWARE  AND  SOFTWARE  CONFIGURATION  BASED 
ON  VENDOR  PRICE  LISTS  DEVELOP  FINAL  REQUIREMENTS  SPECIFICATIONS. 

3.  PREPARE  MANAGEMENT  AND  SUPPORT  PLAN. 

4.  PURCHASE  AND  INSTALL  THE  SYSTEM 

5.  PROV  OE  USER  TRAINING  COURSE  ON  SYSTEM  CAPABILITIES  AND  OPERATION  IVIDEO  TAPE). 


I  l 


LEVEL  OF  EFFORT 

2  PERSON  YEARS  TO  DEFINE  AND  VALIDATE  SYSTEM  REQUIREMENTS  AND  TO  DEVELOP  CUSTOM  MANAGE¬ 
MENT  AND  ENGINEERING  SUPPORT  SOFTWARE.  VENDOR  HARDWARE  COSTS  $4,000  TO  $1C,C00  PER  SYSTEM 
DEPENDING  ON  CONFIGURATION 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND _ 

f  DIGITAL  SYSTEMS  ENGINEER/PROGRAMMER  WITH  3  TO  5  YEARS  OF  MICROPROCESSOR  EXPERIENCE. 


TASK  INPUTS/INTE R F ACE S 

COORDINATION  WITH  TH2  CISF  ENGINEERING/PROGRAMMER  WORK  STATION  DEVELOPMENT  IS  REQUIRED. 
SINCE  THE  WORK  ST  AT  I  ON  MODULES  SHOULD  EVENTUALLY  FULFILL  PART  OF  THE  LOCAL  TOOL 
REQUIREMENTS. 


TASK  DELIVERABLES/KEY  MILESTONES 

1.  SYSTEM  FUNCTIONAL  REQUIREMENTS 

2.  CAPABILITY  COST/BENEFIT  TRADEOFF 

3.  FINAL  SPECIF. ' 'TIONS 

4.  ORDER  AND  DELIVERY 

5.  TRAINING  COURSE  PREPARATION 

6.  CUSTOM  SOFTWARt  DEVELOPMENT 


1982 

1903 

1982 

1983 

-a 

i 

..A 

.figure  5-10.  Automation  and  Standardization  of  ECS  Support  Processes: 

Local  Project  Tool  Development  Summary  Task  Sheet 
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Modula 


TION/ 


SYSTEM 
ACQUISITION 
AND  SUPPORT 


TASK  DESCRIPTION _ MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY _ 

SUBTASK  DESCRIPTION  WORK  STATION  MODULE  SUMMARY  TASK  SHEET _ ^ 

TASK  OBJECTIVES) 


DEVELOP  MULTI  USE  EISF  WORKSTATIONS  FOR  USE  IN  A  DISTRIBUTED  PROCESSING  ENVIRONMENT. 
OVERALL  TASK  ALSO  INCLUDES  DEVELOPMENT  OF  SIMULATION  KERNELS.  REPROGRAMMABLE  CMAC, 
AND  PROGRAMMABLE  INTERFACE  UNIT.  LOCAL  ECS  SUPPORT  NETWORKS  ARE  INCLUDED  WITH  ECS 
SUPPORT  NETWORKS  INITIATIVE. 


MAJOR  ISSUES/PROBLEM  AREAS 


THE  WORKSTATIONS  SHOULD  BE  DEVELOPED  FROM  OFF-THE-SHELF  COMPONENTS  WHENEVER  POSSIBLE 
AND  SHOULD  BE  CAPABLE  OF  SUPPORTING  MULTIPLE  EI$F  COMPUTING  AND  COMMUNICATIONS  TASKS. 
WORKSTATIONS  WILL  HOST  STANDARD  ECS  SUPPORT  TOOLS. 


I  inMrkUaMOfM'KMwOMociai  i 

e*«no»ift*<an£C 


LEVEL  OF  EFFORT 


APPROXIMATELY  24  °ERSON  YEARS  OF  EFFORT  WILL  BE  REQUIRED  TO  BUILD  THE  WORKSTATIONS.  1 

DESIGN  OPERATING  SYSTEM.  AND  INTEGRATE  SYSTEMS  INTO  TWO  BASELINE  ElSF'S  WITH  DIFFERENT  ECS 
SUPPORT  TASKS  OVERALL  INITIATIVE  IS  61  PERSON  YEARS  WITH  12  FOR  SIMULATION  KERNELS.  10  FOR 
^  REPROGRAMMABLE  CMAC  AND  16  FOR  PROGRAMMABLE  INTERFACE  UNIT. 

PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


SYSTEM  DESIGN.  INTEGRATION  TEST.  OPERATIONAL  SUPPORT  INVOLVING  ELECTRONIC.  ELECTRICAL.  AND 
MECHANICAL  ENGINEERING  DISCIPLINES  WITH  EMPHASIS  ON  MICROPROCESSOR  TECHNOLOGY 


\  WOTTM'lo^ii^ iMn comwm 

&  VHIP'AMeHttMIMinnmnMlItMHiiiNQvlliODMMifn 
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TASK  INPUTS/INTERFACES 


TASK  APPROACH 


V  DEVELOP  COMPRF.HENS‘VE  UNDERSTANDING  OF  EtSF  PROCESSING  REQUIREMENTS. 

2.  DEFINE  WORKSTATION  SPECIFICATIONS  FOR  DEVELOPMENT  OF  BASELINE  SYSTEM.  INCLUDING  HARD 
WARE  AND  SOFTWARE 

3.  DESIGN  AND  FABRICATE  PROTOTYPE  SYSTEM. 

4  INTEGRAL  WORKSTATION  Cl/CPCl  AND  INTEGRATE  WORKSTATION  TO  EISF  NETWORK  TEST  AND 
DEMONSTRATE  workstation  utility. 

5  REVISE  SYSTEM  SPECIFICATION  AND  BUY  WORKSTATION  MODULES. 


I  iJjQCTyjrrK.  |T 


n»<iaiKi>  tm*  eno  m  um n  * 


DOD  AND  IEEE  STANDARDS,  COMMUNICATION  FROTOCOLS.  ECS  SUPPORT  TOOL  REQUIREMENTS, 
TARGET  SUBSYSTEM  PROCESSING  AND  CONTROL  REQUIREMENTS,  AND  SUPPORT  SUBSYSTEM  DATA 
EXCHANGE  REQUIREMENTS. 


TASK  OEUVERABLES/KEY  MILESTONES 


-iiw-iai'j 


INPUT  FROM  RELATED  ACTIVITIES 


MANAGEMENT, 
ENGINEERING,  ACQUISITION, 
AND  SUPPORT  PRACTICES 

•  MANAGEMENT,  DIRECTION 

•  PLANNING 

•  POLICY 

•  GUIDANCE 

•  BUDGET 

•  RESOURCES 


AUTOMATION  AND 
STANDARDIZATION  OF 
ECS  SUPPORT  PROCESSES 

•  MANAGEMENT  TOOLS 

•  SUPPORT  TOOLS 

•  PROJECT  TOOLS 

•  PROCEDURES 

•  OATA  BASE 

•  INTERFACE 


ECS  READINESS 
SUPPORT 


INTELLIGENCE 

SECURITY 

DATA  BASE 

PRIORITIES 

THREATS 

TRAINING 


ECS  SUPPORT 
NETWORKS 


•  PROTOCOLS 

•  SECURITY 

•  TRAFFIC 

•  NETWORK  CONTROL 

•  PRIORITIES 

•  ARCHITECTURE 


ATO 

C-E 

EW 


EISF 

REQUIREMENTS 

ANALYSIS 


PRODUCTS 

•  ANALYSIS  REPORTS 

•  SURVEY  REPORTS 

•  CONCEPT  OF  OPERATIONS 

•  EISF  REQUIREMENTS  BY  ECS  CATEGORY 

•  ACQUISITION/FUNDING  PLAN 

•  PROGRAM  MANACEMgNT  DOCUMENTS 


Figure  5-13.  Modular  Extendable  Integration  S 
Workstation  Module  System/ Segi 
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ECS  SUPPORT 
NETWORKS 

>  PROTOCOLS 
i  SECURITY 

(  TRAFFIC 

>  NETWORK  CONTROL 
*  PRIORITIES 

>  ARCHITECTURE 


TASK  DESCRIPTION _ MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  F  ACI LIT V 

WORKSTATION  MOOULt  SYSTEM/SEGMENT  REQUIREMENTS 
SUBTASK  DESCRIPTION  DEFINITION _ 


TASK  OBJECTIVES) 


MAJOR  ISSUES/PROBLEM  AREAS 


WORKSTATION  MUST  SATISFY  A  WIDE  VARIETY  OF  REQUIREMENTS.  FROM  TERMINAL  COMMUNICATIONS 
TO  MULTIPLE  TASK  PROCESSING  Of  LARGE  PROGRAMS  THE  CAPABILITY  OF  THE  WORKSTAI  ION  MUST  BE 
MODULAR  AND  EXPANDABLE 


TASK  APPROACH 


UNIT 

51 


SYSTEM/SEGMENT 

REQUIREMENTS 

VALIDATION 


i  ANALYZE  ATD.  ATE  CC.EW  AND  OF  P  SUPPORT  F  UNCTIONS  TO  IDE  NT  IF  Y  WORKSTATION  APPLICAT  IONS 
TYPE  TOOLS  TO  BE  HOSTED.  AND  COMMUNICATION  REQUIREMENTS 

7  DETEREMINE  FUNCTIONAL  COMMONALITY  FOR  WORKSTATIONS 

3  DETERMINE  SPECIFIC  SUPPORT  TOOLS  NEED  TOSATISFY  RELATED  FUNCTIONS 

4  DEFINE  COMMUNICAT  ION  REQUIREMENTS  WITH  OTHER  SUBSYSTEM  VIA  LOCAL  NETWORK 

6  OE FINE  FUNCTIONAL  REQUIREMENTS  FOR  WORKSTATIONS.  TO  INCLUDE  HARDWARE  SYSTEMSOFT 
WARE,  AND  APPLICATIONS  TOOLS 


LEVEL  OF  EFFORT 


APPROXIMATELY  3  S  PERSON  YEARS  oi  I  FFOR1.  ENGINEER  OR  ANALYST  FROM  E  ACM  ECS  SUPPORT  CATE 
GORY  IATO,  ATE.  C  E  EW.  AND  OEPl  OVtR  SIX  I6>  MONTHS 


PERFORMEFl  EXPERIENCE  LEVEL/BACKGROUND 


ENGINEER /ANALYST  WITH  MINIMUM  OF  FOUR  141  YEARS  EXPERIENCE  IN  WORKSTATION  DESIGN  AND 
APPLICATIONS  A  FIRM  UNDERSTANDING  OF  NETWOHKS  AND  OPERATING  SYSTEMS  HIGHLY  DlSIRABLl 


|  WR-ALC 
P  SM-ALC 
SA-ALC  ~ 
OO-ALC  ""“"l 
oc-alc  I  1 


SURVEY 

AVAILABLE 

ASSETS 


I  LOCAL  NETWORK 
WORK  STATIONS  | 

BUILD  OR 

BUY  — 1 

ANALYSIS 


SYSTEM/SEGMENT 

REQUIREMENTS 

VALIDATION 


PI  UNIT 
SIM  KERNELS* 
CM  AC  "“l 


UNIQUE 

SYSTEM 

SPECIFICATIONS 


DESIGN. 
FABRICATION, 
UNIT  TEST 


SYSTEM 

ENGINEERING 

management 

PLANS 


^  PRODUCTS  j 

•  IN  PLACE  ASSETS  LISTS  1 

•  BUILD-OR-BUY  STUDY  j 

•  TARGET  SYSTEM  SP  ECIF  K; ATICH 

•  engineering  management  pm 

•  ICD'S 


Figure  5-14.  Modular  Extendable  Integration  Support  FaciUj 
Workstation  Module  System/Segment  Required 


TASK  DESCRIPTION . 


MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 


«i  iRTAttt  nttfaiirinu  workstation  module  svstbm/sbqment  requirements  validation  ^ 

TASK  OBJECTIVE(S) 

DEFINITIZE  MODULAR  WORKSTATION  DF.SION  INCLUDING  SPECIFICATIONS  FOR  TERMINALS.  MEMORY 
MODULES.  MASS  STORAGE  MODULES,  AND  OPERATING  SYSTEM  SOFTWARE.  ADDRESS  SECURITY  ISSUES. 


MAJOR  ISSUES/PROBLEM  AREAS 

WORKSTATIONS  MUST  BE  EXPANDABLE  FROM  A  MINIMUM  TERMINAL  TO  A  COMPACT  COMPUTING  SYSTEM 
CONFIGURATION.  HOS*  THE  STANDARD  ECS  SUPPORT  TOOLS  AND  SATISFY  THE  REQUIREMENTS  OF  ECS 
DEVELOPMENT  FOR  C-E,  EW,  OFF  AND  SUPPORT  ATD  AND  ATE  SYSTEM  DEVELOPMENT. 

> _ _ _ 

TASK  APPROACH 

1.  OEVELOP  A  COMMON  LAPSE  TIME  CONFIGURATION  FOR  EACH  ECS  CATEGORY  AND  IDENTIFY  UNIQUE 
REQUIREMENTS.  IF  ANY. 

2.  DETERMINE  MODULE  COMMUNICATION  REQUIREMENTS  AND  ESTABLISH  INTERFACE  SPECIFICATIONS. 

3.  DEVELOP  HARDWARE  SPECIFICATION  AND  OPERATING  SYSTEM  SPECIFICATIONS  TO  INCLUDE  INTER- 
FACE  WITH  LOCAL  NETWORK. 

4.  SURVEY  AVAILABLE  COMMERCIAL  SYSTEMS  TO  SATISFY  REQUIREMENTS. 

5.  CONDUCT  A  BUILD-OR-BUY  ANALYSIS  AND  CAPABILITIES  TRADEOFF  ANALYSIS  FOR  EACH  ECS 
CATEGORY. 


LEVEL  OF  EFFORT 

r~ - - - - - - - - — 

APPROXIMATELY  A  3.8  PERSON  YEAR  EFFORT  IN  A  SIX  MONTH  PERIOD  WITH  MAJOR  WORK  LOAD  DURING 
INITIAL  PHASES. 


PERFORMER  EXPERIENCE  LEVEL/BACKOROUNP _ 

SENIOR  ENGINEER/ANALYST  WITH  MINIMUM  six  161  YEARS  EXPERIENCE  IN  WORKSTATION  DESIGN  OR 
APPLICATIONS  WITH  A  FIRM  UNDERSTANDING  OF  ECS  SUPPORT.  ONE  ENGINEER/ANALYST  MUST  BE  KNOW¬ 
LEDGEABLE  IN  ECS  SUPPORT  IN  EACH  CATEGORY  (ATE.  ATE,  C-E,  EW,  AND  OFP.  ADP  SECURITY  SYSTEM 
KNOWLEDGE  HELPFUL. 

_ _ -  _ _ _ _ _ _ _ J 

TASK  INPUTS/INTERFACES 

f - -  - -  —  —  —  —  ■  —  -  . -  - -i 

KEY  INPUTS  ARE  REQUIRED  FROM  LOCAL  NETWORK  TASKS,  DATA  BASE  MANAGEMENT  SYSTEM  TASK.  AND 
FROM  THE  TARGET  SUBSYSTEM  TASK  IN  ESTABLISHING  SPECIFICATION  AND  CONDUCTING  TRADEOFF 
ANALYSIS. 

_ _ _ _ — - 

TASK  DELIVERABLES/KEV  MILESTONES  1982 


►lace  assets  lists 
Ild-or-buy  study 

RCET  SYSTEM  SPECIF ICA  •  N 
jGINEERINC  MANAGEMENT  PLAN 
»'S 


1.  BASELINE  DOCUMENT  BY  ECS  CATEGORY 

2.  SYSTEM  REQUIREMENT  SPECIFICATION 

3.  INTERFACE  SPECIFICATION 

4.  Cl  DEVELOPMENT  SPECIFICATION 

6.  CPCI  DEVELOPMENT  SPECIFICATION 

6.  COMMERCIAL  SURVEY  RESULTS 

7.  BUILD-OR  BUY  ASSESSMENT 

8.  SDR 


ategration  Support  Facility: 
fstem/Segment  Requirements  Definition 


PR00UCT3 
•  DE 


DESIGN  IMPLEMENTATION  PLANS 
RFP  PACKAGE 
VENDOR  SURVEY  REPORTS 
DESIGN  DOCUMENTS 

•  HARDWARE 

•  SOFTWARE 

FACILITY  DEVELOPMENT  PLANS 


ilMKERNELS 
CM  AC  1 


CODE  LOCAL 
NETWORK,  SIM 
PIU  AND  CM  AC 
SOFTWARE 


UNIT  i 
TEST  J. 
HARDWI 


FABRICATE  BOARDS,  RACKS  STAND  ENCLOSURES, 
CONSOLES  AND  OTHER  SUBSYSTEMS 


PROCURE  OFF-SHELF-EQUIPMENT  AND  SYSTEM  SOFTWARE 
CODE  EISF  SOFTWARE 
TEST  REPORTS 

AUXILIARY  EQUIPMENT,  CABLES 
SPECIAL  TEST  EQUIPMENT 


Figure  5-15, 


Modular  Extendable  Integ 
Workstation  Module  Desi 


TASK  DESCRIPTION  _ 


MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 


SUBTASK  DESCRIPTION  WORKSTATION  MODULE  DESIGN.  FABRICATION.  UNIT  TEST _ 

TASK  OBJECTIVE(S) 


f  detailed  design  ano  development  of  prototype  workstation  modules  and  operating 

SOFTWARE. 


MAJOR  ISSUES/PROBLEM  AREAS 


MAJOR  COMPONENTS  SHOULD  BE  AVAILABLE  ''OFF^THE'SHELF"  WITH  A  MINIMUM  OF  HARDWARE  DESIGN. 
THE  OPERATING  SYSTEM  MAY  REQUIRE  EXTENS ;VE  MODIFICATION  OF  AVAILABLE  CPCI  OR  DEVELOP¬ 
MENT  OF  UNIQUE  SYSTEM  MAY  BE  REQUIRED.  MULTI  LEVEL  SECURITY  MUST  BE  CONSIDERED, 


TASK  APPROACH 


1.  PROCUREMENT  CYCLE  BASED  ON  USE  OF  OPTIMAL  OFF-THE-SHELF  HARDWARE. 

2.  MAJOR  OPERATING  SYSTEM  MODIFICATION  OF  DEVELOPMENT  ANTICIPATED.  WITH  SPECIAL  EMPHASIS 
ON  MULTI  LEVEL  SECURITY  AND  COMPATIBILITY  WITH  ECS  NETWORK  PROTOCOL. 

3  DESIGN  AND  DEVELOPMENT  OF  UNIQUE  INTERFACES.  SOFTWARE  DRIVERS.  CABLING.  ETC. 

4  OPERATING  SYSTEM  SOFTWARE  CODING  AND  DEBUG. 

5.  UNIT  TEST  OF  WORKSTATION  MODULES  AND  SOFTWARE. 


LEVEL  OF  EFFORT 


THIS  IS  APPROXIMATELY  A  10.5  PERSON  EFFORT  OVER  A  PERIOD  OF  14  MONTHS.  HOWEVER.  TOTAL 
WORK  LOAD  WILL  BE  INFLUENCED  BY  the  AVAILABUITY  OF  OFF-THE  SHELF  COMPONENTS  AND 
SOFTWARE 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


HARDWARE  AND  SOFTWARE  ENGINEERS  EXPERIENCED  IN  MICROPROCESSOR.  OPERATING  SYSTEM  SOFT¬ 
WARE,  MANUFACTURING  AND  TESTING  OPERATING  SYSTEM  AND  MULTI-LEVEL  SECURITY  EXPERTS 
ESSENTIAL. 


TASK  INPUTS/INTERFACES 


SECURITY  REQUIREMENTS.  ECS  NETWORK  COMMUNICATION  PROTOCOL  SPECIFICATION.  NETWORK  SEG¬ 
MENT  EQUIPMENT  STANDARDS.  COORDINATE  WITH  FACILITY  PLANNERS. 


TASK  DELIVERABLES/KEY  MILESTONES 


1.  DESIGN  IMPLEMENTATION  PLAN 

2.  MANUFACTURE/VENDOR  SUPPLY 

3.  PREPARE  AND  ISSUE  RFP'S 

4.  VENDOR  PROPOSAL  EVALUATION 

5.  UNIQUE  INTERFACE  DESIGN 

6.  PDR  AND  CDR 

7.  OPERATING  SYSTEM  SOFTWARE 
DESluN 

8.  FABRICATE  UNIQUE  HARDWARE 

9.  OFF-THE-SHELF  EQUIPMENT 
PROCUREMENT  AND  TEST 

10.  OPERATING  SYSTEM  SOFTWARE 
CODE  AND  TEST 


Extendable  Integration  Support  Facility: 

;on  Module  Design,  Fabrication,  Unit  Test 


w 


PRODUCTS 


TEST  PROCEDURES,  UNIQUE  TEST  EQUIPMENT) 
TEST  REPORTS  \ 

S  YSTEM  MODIFICATION  RECOMMENDATIONS 
OPERATIONAL  EISF'S  (MINIMAL  OF  TWO) 


i^r  hf'i  fn 
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TA»K  DESCRIPTION  MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 
SUBTASK  PEtCRIPTION  WORKSTATION  MODULE  CI/CPCl  INTEOWATlON/TItT-  ...  . 


TASK  OBJECTIVES) 


INTEGRATION  AND  TEST  OF  WORKSTATION  CI/CPCl  WITH  THE  LOCAL  NETWORK.  CWCRCI'S  INCLUDE  OFF- 
THE-SHELF  AND  UNIQUE  SOFTWARE.  HOST  THE  STANDARO  ECS  SUPPORT  TOOLS. 


INTEGRATE 
TARGET  SUB¬ 
SYSTEM 
CI/CPCl 


ALL  COMPONENTS 


SYSTEM 

INTEGRATION 

TESTING 


EQUIPMENT,  TEST  PLANS 

[NDATIONS 

TWO) 


TASK  INPUTS/INTERFACES _ 

DETAILED  INFORMATION  ON  ALL  INTERFACES,  SUBSYSTEMS.  AND  APPLICATION  SUPPORT  SOFTWARE 
TOOLS 


TASK  DELIVERABLES/KEY  MILESTONES 


t.  DEVELOP  TESTS/TEST  PROCEDURES, 
CI/CPCl 

J.  DEVELOP  LOCAL  NETWORK  TEST 
PROCEDURES 

3.  DEVELOP  UNIQUE  TEST  EQUIPMENT/ 
SOFTWARE 

4.  PERFORM  Cl/CPCI  INTEGRATION  TEST 

5.  PERFORM  EISF  NETWORK  INTEGRA 
TION/TEST 

6.  HOST  EISF  SUPPORT  TOOLS 

7.  TEST  AND  VALIDATE  EISF  SUPPORT 
TOOLS 

8  EISF/UTILITY  DEMONSTRATION 

«.  FUNCTIONAL  CONFIGURATION 
AUDIT 

10  PHYSICAL  CONFIGURATION  AUDIT 

IV  KERNEL  QUALIFICATION  REVIEW 


endable  Integration  Support  Facility: 
Module  CI/CPCl  Integration/Test 
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PRODUCTS 

•  UPDATED  IMPLEMENTATION  PLANS  FROM  EACH  AL< 
REVISE  SPECIFICATIONS  FOR  ALL  SYSTEMS  TO  BE  P( 
TRAINING  COURSE  PLANS  AND  MATERIALS 


ALL  COMPONENTS  REQUIRED  FOR  MULTIPLE  EISF,  j 
ON-HAND  COMPONENT  FOR  EXPANSION,  NEW  REQUlJj 

•  FACILITIES  FOR  HOUSING  EISF'S  '] 

•  OPERATIONAL  EISF'S,  WITH  OPERATIONS  MANUALS, 
CONFIGURATION  DOCUMENTS 

•  EISF  OPERATIONS  INSTRUCTION  AND  OVER-THE-SHO* 

•  TEST  REPORTS 

•  UPDATED  DOCUMENTS 

•  SYSTEM  LIBRARY  WITH  SYSTEM  DOCUMENT  I 

•  DATA  COLLECTION/ ANALYSIS  SOFTWARE  j 

•  OPERATIONAL  REPORTS  (DEFICIENCIES,  FAILURES)  f 

•  MAINTENANCE  REPORTS  (TYPE  MAINTENANCE,  LOOj 

SUPPORT  PROBLEMS,  ETC.)  1 


Figure  5-17. 


Modular  Extendable 
Workstation  Module 


SYSTEM 

documentation 

UPDATE 


SYSTEM 

DOCUMENTATION 

UPDATE 


TASK  INPUTS/INTERFACES 


INTERFACES  WITH  THE  NETWORK  DESIGN  TEAM,  TARGET  SUBSYSTEM  SUPPORT  DESIGN  TEAMS,  AND  DATA 
BASE  MANAGEMENT  SYSTEM  DESIGN  TEAM. 


M  EACH  ALC  USING  EISF 
EM5  TO  BE  PROCURED 
$ 

TIPLE  EISF,  INCLUDING 
NEW  REQUIREMENTS,  ETC. 


m 


MANUALS, 


VER-THE-SHOULDER  TRAINING 


S,  FAILURES) 
ENANCE,  LOGISTICS 


TASK  DELIVER  A8l.ES/KEY  MILESTONES 

r  .  -  — 

1.  REVISED  WORKSTATION  SPECULATIONS 
?.  TRAINING  COURSE  MATERIALS,  PLANS.  MANUALS 
3.  CISF  TRAINING  SUPPORT 


Extendable  Integration  Support  Facility: 
on  Module  System  Acquisition  and  Support 
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TASK  DESCRIPTION. 


MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 


SUBTASK  DESCRIPTION  simulation  kernels  system/segment  requirements  VALIDATION  ^ 
TASK  OBJECTIVE(S) 

DEFINE  SIMULATION  KERNEL  SPECIFICATIONS  FOR  EACH  CANDIDATE  APPLICATION.  TO  INCLUDE  TYPE- 
SIMULATION.  I/O  REQUIREMENTS.  COMMON  CORE  UNITS.  SPECIAL  UTERFACE  NEEDS 


MAJOR  ISSUES/PROBLEM  AREAS 

f  SIMULATION  KERNELS  MUST  OPERATE  IN  STAND  ALONE  MODE  OR  UNDER  THE  CONTROL  OF  A  WORK  STA 
TION  THROUGH  COMMAND  PROVIDED  BY  NETWORK  COMMUNICATION. 


TASK  APPROACH 

- — - - - - - - - 

1.  DEVELOP  A  COMMON  BASELINE  CONFIGURATION  FOR  EACH  SIMULATION  APPLICATION  AND  IDENTIFY 
UNIQUE  REQUIREMENTS.  IF  ANY. 

2  ESTABLISH  SYSTEM  COMMUNICATIONS  RETIREMENTS  FOR  EACH  APPLICATION 
3.  DEVELOP  HARDWARE  SPECIFICATION  FOR  EACH  APPLICATION  TO  INCLUDE  DATA  CONVERSION 
MODULES. 

4  DEVELOP  APPLICATION  SOFTWARE  SPECIFICATIONS  TO  INCLUDE  COMMUNICATION  AND  CONTROL 
MODULES 

5.  SURVEY  COMMERCIALLY  AVAILABLE  MICROPROCESSOR  BOARDS.  COMPONENTS,  ETC. 

6.  CONDUC.I  A  BUILDOR  BUY  ANALYSIS. 


LEVEL  OF  EFFORT 

f  APPROXIMATELY  1.5  PERSON  YEARS  ARE  REQUIRED  OVER  A  6  MONTH  PERIOD 


PERFORMER  EXPERIENCE  LEVEUBACKGROUNO _ 

SENIOR/ENGINEER  ANALYST  WITH  A  MINIMUM  OF  SIX  161  YEARS  EXPERIENCE  IN  SIMULATION  DESIGN  AND 
MICROPROCESSOR  APPLICATIONS  A  FIRM  UNDERSTANDING  OF  ECS  SUPPORT  AND  EQUIPMENTS  AND  INTE 
GRATED  SUPPORT  SY<  'EM  DESIGN  IS  ESSENTIAL 

L  -  _ _  _  _  —  — 

TASK  INPUTb/INTERFACES 

INPUTS  FROM  NETWORK  AND  WORK  STATION  DESIGN  EFFORTS  TO  ENSURE  COMPATIBLE  COMMUNICATION 
AND  CONTROL  MODES.  PROGRAMMABLE  INTERFACE  UNIT  SPECIFICATIONS 


TASK  OEUVERABLES/KEY  MILESTONES 


1.  BASELINE  REQUIREMENTS  DOCUMENTATION 

2.  SYSTEM  INTERFACE  REQUIREMENTS 

3.  Cl  DEVELOPMENT  SPECIFICATION 

4.  CPCI  DEVELOPMENT  SPECIFICATION 
6.  PERFORM  VENDOR  SURVEY 

6.  PERFORM  BUILD  OR  BUY  ANALYSIS 


Figure  5~?0.  Modular  Extendable  Integration  Support  Facility: 

Simulation  Kernels  System/ Segment  Requirements  Validation 
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TASK  DESCRIPTION _ MODULAR  EXTENDABLE  INTEQRATION  SUPPORT  FACILITY 

SUBTASK  DESCRIPTION  SIMULATION  KERNELS  DESIGN.  FABRICATION.  UNIT  TEST 


TASK  OBJECTIVES) 

f  DETAILED  DESIGN  AND  DEVELOPMENT  OP  CANDIDATE  SIMULATION  KERNELS. 


MAJOR  ISSUES/PROBLEM  AREAS 

KERNEL  DESIGN  WILL  BE  BASED  ON  COMMERCIALLY  AVAILABLE  MICROPROCESSOR  WITH  MATURE  DEVEL¬ 
OPMENT  SYSTEM  AND  SUPPORT  eASE. 

_ _ J 

TASK  APPROACH 

C - - - — — - - - \ 

1  PROCUREMENT  CYCLE  BASED  ON  OFF  THE  SHELF  HARDWARE  WITH  UNIQUE  SOFTWARE 

2  SURVEY  APPLICABLE  MICROPROCESSORS  AND  SUPPORT  SYSTEMS. 

3.  DESIGN  AND  DEVELOP  ANY  UNIQUE  HARDWARE,  INTERFACES. 

4.  FABRICATION  OF  ALL  HARDWARE 

6.  CODING  OF  SIMULATION  AND  COMMUNlCATlON/CONTROL  MODULES. 

6  UNIT  TEST  OF  SIMULATION  KERNEL  HARDWARE  AND  SOFTWARE. 

1 


V _ J 

LEVEL  OF  EFFORT _ 

f  THIS  IS  APPROXIMATELY  r  6  PERSON  YEAR  EFFORT  OVER  A  PERIOD  OF  U  MONTHS  1 


PERFORMER  EXPERIENCE  LEVEUBACKGP.OUND _ 

HARDWARE  AND  SOFTWARE  ENGINEER  WITH  EXPERIENCE  IN  SIMULATION  DESIGN  AND  DEVELOPMENT, 
MICROPROCESSOR  PROGRAMMERS  SKILLED  N  APPROVED  DOD  HOL  S. 


I 

$ 

1 


TASK  IMPUTS/INTERFACES 

r  '  "  '  *  —————————  ■  -  L'\ 

COMMUNICATION  REQUIREMENTS  WITH  NETWORK  AND  CONTROL  INTERFACES,  WITH  WORK  STATIONS. 

FILE  SEQUENCES.  AND  PROGRAMMABLE  INTERFACE  UNITS, 


. _ 

TASK  DELIVERABLES/KEY  MILESTONES 

1983 

1984 

MONTH 

'I *1  3|«|  5|  6j  7(bU|  10I  ll|  IS 

1 3 1  u|  15]  1 6 1  1  ?j  18 

1.  DESIGN  IMPLEMENTATION  PLANS 

■A 

2.  MICROPROCESSOR  UNDER  SURVEY 

3.  PREPARE  ANO  ISSUE  RFPS. 

A 

4.  VENDOR  PROPOSAL  EVALUATION 

_A 

B  PDRANDCDR 

A _ A 

S.  FABRICATION  OF  UNIQUE  HARDWARE 

_ A 

7.  SIMULATION  DESIGN 

_ A 

8  CFF  THE  SHELF  EQUIPMENT  PROCURE- 

MENT  AND  PACKAGING  TEST 

-  A.A 

9  SIMULATION  COOING  ANO  TEST 

A _ A _ A  1 

Figure  5-21.  Modular  Extendable  Integration  Support  Facility: 

Simulation  Kernels  Design,  Fabrication,  Unit  Test 
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TASK  DESCRIPTION _ MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 

SUBTASK  ngRCRIPTIQN  SIMULATION  KERNELS  Cl/CPCt  INTEGRATION  AND  TEST 
TASK  OBJECTIVES) 

INTEGRATE  SIMULATION  KERNELS  INTO  THE  El$F  NETWORK. 


MAJOR  ISSUES/PROBLEM  AREAS 


TASK  DELIVERABLES/KEY  MILESTONES  i®S4 


1.  DEVELOP  TEST  PROCEDURES.  CI/CRCI 
7.  DEVELOP  EISF  NETWORK  TESTS 
3  DEVELOP  UNIQUE  TEST  EQUIPMENT 

4.  PERFORM  CI/CPCI  INTEGRATION  AND  TEST 

5.  PERFORM  NETWORK  INTEGRATION  TESTS 

6.  VALIDATE  SIMULATIONS  (FUNCTIONAL) 

7.  FUNCTIONAL  CONFIGURATION  AUDIT  (FCA) 

8.  PHYSICAL  CONFIGURATION  AUDIT  (PUA) 

9  FORMAL  QUALIFICATION  REVIEW  IFQR) 


re  5-22.  Modular  Extendable  Integration  Support  Facility: 

Simulation  Kernels  CI/CPCI  Integration  and  Test 
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Figure  5-?.3,  Modular  Extendable  Integration  Support  Facility: 

Simulation  Kernels  System  Acquisition  and  Support 
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TASK 


SUBTASK  ritSmiPTIOM  REPROGRAMMABLE  CM»C  SUMMARY  TASK  SHEET 
TASK  OBJECTIVES) 


TASK  DESCRIPTION _ 

SUBTASK  DESCRIPTION. 
TASK  OBJECTIVES) 


MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 

REPROGRAMMABLE  CMAC  SYSTEM/SFGMENT  REQUIREMENTS 
DEFINITION  _ 


DEFINE  CONCEPTUAL  APPROACH  AND  FUNCTIONAL  REQUIREMENTS  FOR  REPROGRAMMABLE  CMAC. 


MAJOR  ISSUES/PROBLEM  AREAS 


REPROGRAMMABLE  CMAC  MUST  MONITOR  TARGET  ECS  OF  VARYING  SPEEDS  AND  ARCHITECTURE  WITH 
MAXIMUM  CMAC  STANDARDIZATION, 


TASK  APPROACH 


1  ANALYZE  ECS  INTERFACE  SIGNALS  TO  SEVERAL  REPRESENTATIVE  ECS. 

2.  DEFINE  CMAC  BREAK  POINT  DATA  COLLECTION  CAPABILITIES. 

3  DEFINE  MEANS  OF  CAPTURING  ECS  INTERFACE  SIGNALS  FROM  TARGET  ECS. 

4.  DEFINE  OUTPUT  INTERFACE  REQUIREMENTS  TO  HOST. 

5.  DEFINE  FUNCTIONAL  PROCESSING  REQUIREMENTS. 


LEVEL  OF  EFFORT 


ABOUT  1.5  PERSON  YEARS  WITH  ABOUT  1  PERSON  YEAR  OF  EFFORT  CONCENTRATING  ON  THE  PROBLEMS 
ASSOCIATED  WITH  RETARGETING  THE  COMPUTER  MONITOR  AND  CONTROL  UNIT. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


DIGITAL  SYSTEMS  ENGINEERS  WITH  7  YEARS  EXPERIENCE  IN  DESIGN  AND  INTERFACING  OF  DIGITAL  SYS¬ 
TEMS.  FIRM  UNDERSTANDING  OF  COMPUTER  ARCHITECTURE  REQUIRED. 


TASK  INPUTS/INTERFACES 


INPUTS  REQUIRED  FROM  STUDIES  WHICH  ALLOCATE  NEW  ECS  SYSTEMS  TO  EISF  FAMILIES.  AND  CONCEP¬ 
TUAL  DEFINITION  O.  THE  OVERALL  EISF  ARCHITECTURE.  INTERFACE  WITH  PROGRAMMABLE  INTER¬ 
FACE  UNIT  IPIU)  DEFINITION. 


TASK  DELIVERABLES/KEY  MILESTONES 


1982 


MONTH 

1  |  J  |  3  |  4  |  5  |  6 

1.  ANALYZE  TARGET  INTERFACE  REQUIREMENTS  FOR 

SEVERAL  SELECTED  EMBEDDED  COMPUTERS 

2.  DEFINE  CMAC  DATA  COLLECTION  ANO  ECS  CONTROL 

CAPABILITIES 

■  —  A 

3.  DETERMINE  MEANS  OF  GATHERING  TARGET  ECS 

INTERFACE  SIGNALS 

_ & 

4.  SELECT  REPRESENTATIVE  HOSTS  AND  DETERMINE 

CMAC  TO  HOST  INTERFACE 

A 

5.  DEFINE  CMAC  FUNCTIONAL  PROCESSING 

REQUIREMENTS 

- k 

6.  SYSTEM  REQUIREMENTS  REVIEW  (SRR) 

_  — - n 

\ 

«. _ . _ 

_ _ ^ 

Figure  5-25.  Modular  Extendable  Integration  Support  Facility: 

Reprogrammable  CMAC  System/ Segment  Requirements  Definition 
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TASK  DESCRIPTION  MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 

REPROGRAMMABLE  CMAC  SYSTEM/SEGMENT  REQUIREMENTS 
SUBTASK  DESCRIPTION  _  VALUATION _ 

TASK  OBJECTIVE(S) 

VALIDATE  REPROGRAMMABLE  CMAC  FUNCTIONAL  LEVEL  REQUIREMENTS  AND  WRITE 
SPECIFICATIONS. 


MAJOR  ISSUES/PROBLEM  AREAS 

f - - - * - - - -  -  ■  ~ 

CMAC'S  BUILT  OF  OF F  TH6  SHELF  MODULES  WHICH  ARE  SOFTWARE  REPROGRAMMABLE  MAY  NOT  KEEP 
UP  WITH  TARGET  ECS  INPUT  DATA  THE  AMOUf/T  OF  CUSTOM  HARDWARE  REQUIRED  NEEDS  TO  BE 
DETERMINED  BY  TIMING  ANALYSIS 

- -  —  _ _ _ _  .  _ _ 

TASK  APPROACH 

•  ■■  —  —  ■  — -  - — — - 

t.  PERFORM  TIMING  ANALYSES  OF  FUNCTIONAL  PROCESSING  REQUIREMENTS 

•  INPUT  OATA  CONTROL 

•  INPUT  OATA  PROCESSING 

•  DATA  COLLECTION  AND  OUTPUT  TO  HOST 

•  CMAC  CONTROL  FUNCTIONS 

2.  DEFINE  BOARD  LEVE L  THROUGHPUT  REQUIREMENTS 

3.  PERFORM  VENDOR  SURVEY  TO  FIND  OFF-THE-SHELF  BOARDS  WHICH  MEET  REQUIREMENTS. 


LEVEL  OF  EFFORT _ 

f  APPROXIMATELY  ONE  PERSON  YEAR  WITH  ABOUT  HALF  THE  EFFORT  IN  TIMING  STUDIES 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUNP 

f  DIGITAL  SYSTEMS  ENGINEERS  WITH  S  YEARS  EXPERIENCE  IN  DIGITAL  SYSTEMS  DESIGN. 


TASK  INPUTS/INTERFACES _ 

f  INTERFACES  WITH  PROGRAMMABLE  INTERFACE  UNIT  (PIUI. 


TASK  DELIVERABLES/KEY  MILESTONES 

r  ~  _  -  .  ■ 

V  TIMING  ANALYSES 

2.  CMAC  BOaF  D  LEVEL  THROUGHPUT  REQUIREMENTS 

3.  PtRFORM  VENDOR  SURVEY 

4.  PUBLISH  REQUIREMENTS  SPEC  AND  ICO 

5.  PERFORM  TRADEOFFS.  BUILD  OR  BUY.  CUSTOM  VS 
OFF  THE  SHELF 

6  SYSTEM  DESIGN  REVIEW  SDR 


MONTH  1  1  |  2  I  3  I  4  I  516 


Figure  5-Z6.  Modular  Extendable  Integration  Support  Facility: 

Reprogrammable  CMAC  System/ Segment  Requirements  Validation 


MODULAR  EXTENDABLE  INTECRAT ION  SUPPORT  FACILITY 


TASK  DESCRIPTION 

SUBTASK  DESCRIPTION  REPROGRAMMABLE  CMAC  PREL'MlNARY  AND  DETAILED  DESIGN 


TASK  OBJECTIVES) 


PERFORM PRELIMINARY  AND  DETAILED  DESIGN  OT  REPROGRAMMABLE  CMAC  MAKING  MAXIMUM  USE  OF 
OFF-THE-SHELF  MODULES- 


MAJOR  ISSUES/PROBLEM  AREAS 

REPROGRAMMABLE  BOARD  TIMING  CANNOT  BE  ACCURATELY  DETERMINED  UNTIL  THE  ACTUAL  INSTRUC¬ 
TION  SEQUENCE  REQUIRED  TOPERFORM  THE  NECESSARY  FUNCTIONS  IS  SPECIFIED. 

- - . 

TASK  APPROACH 

- — - - - v 

1  ORGANIZE  DESIGN  AND  IMPLEMENTATION  TEAM  FOR  PROPOSAL  EVALUATION  AND  CONTRACTOR 
MANAGEMENT. 

2.  WRITE  DESIGN/IMPLEMENTATION  PLAN 

3  SUPPORT  PROPOSAL. 

4  EVALUATE  PROPOSAL.  SELECT  CONTRACTOR.  AWARD  TASK. 

5.  DESIGN  TARGET  ECS  INTERFACE  BOARDS 

6  SSLECT/DE$IGN  CMAC  PROCESSING  BOARDS  ANO  PROCESSING  SOFTWARE. 

7  FINALIZE  DESIGN  AND  PUBLISH  D'iSIGN  SPECIFICATIONS 


LEVEL  OF  EFFORT 

ABOUT  2  5  PERSON  YEARS  OF  DESIGN  TE  AM  E F  FORT 

1 _  _  __  __ 

PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

DIGITAL  SYSTEMS  ENG.NEERS.  DIGITAL  DESIGNERS  WITH  A  BACKGROUND  IN  MICROPROCESSOR 
MONITORING  ANO  CONTROL  EXPERIENCE  WITH  DIGITAL  INTERFACES  DESIGN  IS  ESSENTIAL. 

L - . - 

TASK  INPUTS/INTERFACES  _ 

IT  IS  .  NTlCIPATED  THAT  RACKS.  POWER  SUPPLIES.  AND  PROCESSING  BOARDS  ARE  AVAILABLE  OFF-THE- 
SHELF.  THE  BACKPLAIN.  THE  INPUT  BOARD,  ANO  POSSIBLY  OUTPUT  FiOARD  MAY  HAVE  TO  BE  CUSTOM 
DESIGNED.  COORDINATE  WITH  PIU. 


TASK  DELIVERABLES/KEY  MILESTONES  *987  1983 


Figure  5-27.  Modular  Extendable  Integration  Support  Facility: 

Reprogrammable  CMAC  Preliminary  and  Detailed  Design 
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TASK  DESCRIPTION  MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 

SUBTASK  DESCRIPTION  REPROGRAMMABLE  CMAC  SYSTEM  INTEGRATION  AND  TEST 


TASK  OBJECTIVES) 

1  1  - * - _  — , ,  -  -  -  — 

INTEGRATION  AND  TEST  OF  Cl/CPCI  INTO  AN  OPERATING  REPROGRAMMABLE  COMPUTER  MONITOR 
AND  CONTROL  UNIT. 


MAJOR  ISSUES/PROBLEM  AREAS 

/  ■■  “  ""r_  _  ■  ■  _  -  --< 

INTEGRATION  TEST.NG  WILL  BE  LIMITED  TOTHE  SYSTEMS  SELECTED  FOR  THIS  BASELINE 
DEMONSTRATION. 


TASK  APPROACH 

1  WRITE  INTEGRATION  PLAN,  SYSTEM  TEST  PLAN.  AND  PROCEDURES 

2.  DESIQN/BUILD/OtJTAlN  SPECIAL  TEST  HARDWARE  AND  SOFTWARE 

3  PERFORM  INTEGRATION  TO  ACHIEVE  OPERATING  COMPUTER  MONITOR  AND  CONTROL  UNIT 

4  PERFORM  SYSTEM  TEST  AND  CORRECT  DEFICIENCIES 

5  WRITE  TEST  REPORTS 

6.  REDLINE  DESIGN  DOCUMENTS  TO  " AS-BUILT”  CONFIGURATION. 


LEVEL  OF  EFFORT _  _ 

[APPROXIMATELY  2.5  PERSON  YEARS,  WITH  ABOUT  \  PERSON  YEAR  REQUIRED  FOR  COMPUTER  MONITOR 
AND  CONTROL  INTEGRATION, 


PFRFORMER  EXPERIENCE  LEVEL/BACKGROUND 

jT-  ■  ■  - — —  -  —  - 

DIGITAL  SYSTFM  INTEGRATION  AND  TEST  ENGINEERS  WITH  A  MINIMUM  OF  10  YEARS  EXPERIENCE.  SUP¬ 
PORTED  BY  DIGITAL  HARDWARE  TECHNICIANS  WITH  5  YEARS  APPLICABLE  EXPERIENCE. 


TASK  INPUTS/INTERFACES 

(PROGRAMMABLE  INTERFACE  UNIT  INTE  ORATION/ TEST  COORDINATION. 


TASK  DELIVERABLES/KEY  MILESTONES 


|  1.  WRITE  INTEGRATION  PLAN 

2.  DEVELOP  TESTS/PROCEDURES  AND  SPECIAL  TEST 
SOFTWa,RE  AND  TEST  HARDWARE 

3.  PERFORM  CP'CPCl  INTEGRA  1  ION  AND  TEST 

4.  PERFORM  CMAC  SYSTEM  TEST 

5  FUNCTIONAL  CONFIGURATION  AUDIT  ‘FCAI 

6  PHYSICAL  CONFIGURATION  AUDIT  (PCA) 

.  7.  FORMAL  QUALIFICATION  REVIEW  1FQR) 


MONTH  |  1  1  2 1  3l4l5l6l?|8l9l 


Figure  5-29.  Modular  Extendable  Integration  Support  Facility: 

Reprogrammable  CMAC  System  Integration  and  Test 


v 


TASK  DESCRIPTION. 


SUBTASK  I 


TASK  OBJECTIVE  IS) 


THE  CMAC  SHOULD  PE  FULLY  OPERATION*!.,  ANO  TRAINING  OF  OPERATION  AND  SUPPORT  PERSONNEL 
TIONOF  OPEURATf|ONA|:  PnoeLtMSDESIQN  SI>€Clf  ICATl0N  SHOULD  BE  UPDATED  TO  REELECT  RESOLU  L 

MAJOR  ISSUFS/PROBLEM  AREAS 

OPERATIONAL  EXPERIl'NCC  WILL  PROVIDE  VALUABLE  INSIGHT  INTO  DESIGN  IMPROVEMENTS  Which 
SHOULD  BE  INCORPORATED  INTO  EUTURE  REPROGRAMMABLE  CM  SC’S  improvements  WHICH 


TASK  APPROACH 

I  PUBLISH  "AS-BUILT"  documentation. 

2.  WRITE  OPERATION  ANO  SUPPORT  MANUALS. 

3  DEVELOP  TRAINING  COURSE  MATERIALS. 

A.  CREATE  EILE  OE  OPERATIONAL  DEFICIENCY  REPORTS 
5.  REFINE  CMAC  DESIGN  BASED  ON  OPERATIONAL  DEFICIENCIES 


LEVEL  OF  EFFORT _ 

ONE  PERSON  YEAR  IS  REQUIRED,  PI  3ARII  Y  FOR  WRITING  OPERATION  AND  SUPPORT  MANUALS  AND 
OPERATOR/MAINTENANCE  TRAINING  MATERIALS.  HU  suituki  MANUALS  AND 


PERFORMER  EXPERIENCE  LEVEL/BACKOROUND  _ 

EXPEmENCETASKS  REQU'RE  °'GITAL  HARDWARE  AND  SOFTWARE  ENGINEERS  WITH  f  1  O  7  YEARS  OF 


TASK  INPUTS/INTERFACES 

f  FEEDBACK  ON  DESIGN  FEATURES  AND  LIMITATION  FOR  FUTURE  SYSTEM  UPDATES. 


TASK  DELIVERABLES/KEY  MILESTONES _ 

1.  ESTABLISH  DOCUMENTATION  LIBRARY 

2.  WRITE  OPERATION  AND  SUPPORT  MANUAL 

3.  DEVELOP  TRAINING  COURSE 

4.  PRESENT  TRAINING  COURSE 

5  UPDATE  SYSTEM  DESIGN  BASED  ON  OPERATIONAL 
EXPERIENCE 


MONTH  |  I  |  2|  3l  4  I  S|  6l  7  I  gl  9 


_AA 


Figure  5-30.  Modular  Extendable  Integration  Support  Facility: 

Reprogrammable  CMAC  Operation  and  Support 


TASK  DESCRIPTION . 


LAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITY 


SUBTASK  description  programmable  interface  unit  summary  task  sheet _ 

TASK  OBJECTIVES) 

design  a  flexible  interface  which  can  support  a  multitude  of  nonhomogenous  aRCHItec 

TURES  THROUGH  SOFTWARE  CONTROL,  CONVERSION,  AND  DATA  MANIPUI  ATION  IN  REAL  TIME.  FOCUS 
WILL  BE  ON  STANDARD  BUS  AND  ARCHITECTURE 

MAJOR  ISSUES/PROBUM  AREAS 

f  PROGRAMMABLE  INTERFACE  UNITS  MUST  BE  COMPATABLE  WITH  THE  SIMULATION  KERNELS.  PRO¬ 
GRAMMABLE  CMACS,  HOST  COMPUTERS  AND  THE  EISF  NETWORK, 


TASK  APPROACH 

t.  DEFINE  ALL  EISF  INTERFACE  REQUIREMENTS  AND  CONDUCT  TRADEOFF  ANALYSIS. 

2.  DEFINE  SPECIFICATIONS  FOR  INTERFACE  UNITS. 

3  DLSlGN  AND  FABRICATE  CANDIDATE  INTERFACE  UNITS  AND  CODE  THE  SOFTWARE. 

4.  CONDUCT  Cl/CPCI  INTEGRATION  AND  TESTING. 

5.  REVISE  SYSTEM  SPECIFICATION  AND  PURCHASE  INTERFACE  MODULES. 


LEVEL  OF  EFFORT 

s — - - — — — - - - - - - — -  —  —  —  —  - 

APPROXIMATELY  15  PERSON  YEARS  OF  EFFORT  WILL  BE  REQUIRED  TO  BUILD  AND  TEST.  EXCLUSIVE  OF 
THE  TIME  DEVOTED  TO  THE  SIMULATION  KERNEL  AND  PROGRAMMABLE  CMAC  INTERFACE  DESIGN.  FAB 
R  CATION.  AND  TEST. 

PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

- - - 

SYSTEMS  DESIGN.  INTEGRATION  TEST.  OPERATIONAL  SUPPORT  INVOLVING  ELECTRONIC  AND  SOFTWARE 
ENGINEERS  WITH  STRONG  MICROPROCESSOR  AND  SYSTEM  INTERFACING  BACKGROUNDS. 


TASK  INPUTS/INTERFACES _ 

(interface  REQUIREMENTS  ANO  DESCRIPTIONS  FOR  ALL  EISF  SUBSYSTEMS  AND  ECS  HOSTS 


TASK  DEUVERABLeS/KEV  MILESTONES 

r  -  —  - 

1.  REQUIREMENTS  DEFINITION 
2  REQUIREMENTS  VALIDATION 

3.  DESIGN.  FABRICATION.  AND  UNIT  TEST 

4.  Cl/CPCI  INTEGRATION  AND  TEST 

5.  PROCUREMENT  AND  OPERATIONS  SUPPORT 


Figure  5-31.  Modular  Extendable  Integration  Support  Facility: 

Programmable  Interface  Unit  Summary  Task  Sheet 
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IJVIlf  THREAT 
ANALTM* 

car&biTitv 

ACQUISITION 


TASK  DESCRIPTION. 


SUBTASK  I 


TASK  OBJECTIVES) 


DEVELOPMENT  OP  AN  APLCECS  READINESS  SUPPORT  CAPABILITY  TO  INCLUDE:  II  THE  ESTABLISHMENT  OF 
THE  REQUIRED  INTELLIGENCE  SUPPORT  ORGANIZATIONS,  21  THE  ACQUISITION  OF  THE  REQUIRED  SOFT- 
WARE  AP'O  HARDWARE  TOOLS,  3)  THE  DEVELOPMENT  ANO  MAINTENANCE  OF  THE  NECESSARY  AUTOMATED 
SUPPORT  DATA  BASES.  41  THE  ACQUISITION  OF  THE  REQUIRED  SUPPORT  FROM  OTHER  AIR  FORCE 
ORGANIZATIONS,  SI  THE  ESTABLISHMENT  OF  THE  NECESSARY  RESOURCES.  SI  APPROPRIATE  IMPLEMENTA¬ 
TION  IN  AIR  FORCE  REGULATIONS.  AND  71  THE  MOMFILATIONS  OF  VARIOUS  ISS/IJF  TO  ACCOMMODATE 
THIS  ACTION 

_  .  ,  - - - -  ,  ■  ■  — .  ■  —  - 

MAJOR  ISSUES/PROBLEM  AREAS 

- : - 

1.  RESOURCES. 

2.  COMMITMENT  TO  LONG  LEAD  TIME  ACQUISITION  PROCESS. 

3  AIR  FORCE  WIDE  SUPPORT. 

4.  UNDERSTANDING  OF  PROBLEM  BV  OTHER  AF  /.GENCIES,  DOO.  JCS,  AND  CONGRESS. 

TASK  APPROACH 

- - . - - - - - - - - - - — — —  N 

1.  ESTABLISHMENT  OF  AN  AFLC  ECS  READINESS  CAPABILITIES  MANAGEMENT  ORGANIZATION. 

2.  DEVELOPMENT  AND  MAINTENANCE  OF  A  PRIORITIZED  ECS  READINESS  SYSTEM/S'JBSYSTEM  LISTING. 

3.  ECS  READINESS  CONCEPT  OF  OPERATIONS  DEVELOPMENT  ANO  APPROVAL. 

4.  ESTABLISHMENT  OF  AFLC  ECS  INTELLIGENCE  SUPPORT  CAPABILITY. 

5.  IDENTIFICATION  OF  AFLC  INTELLIGENCE  ACCESS  REQUIREMENTS. 

B.  DEVELOPMENT  OF  ISS/ISF  THREAT  IMPACT  ANALYSIS  CAPABILITY. 

7  DETERMINATION,  REPORTING  AND  STORING  OF  SELECTED  ECS  REACINESS  SYSTEM/SUBSYSTEM 
SENSITIVITIES/VULNERABILITIES. 

8.  OBTAIN  CAPABILITY  TO  USE  FLIGHT  DATA  IN  ISS/ISF. 

9.  ESTABLISHMENT  OF  ECS  READINESS  iSS/ISF  PREEMPTIVE  ENGINEERING  CAPABILITY. 

10.  IDENTIFICATION  OF  ECS  READINESS  CONFIGURATION  MANAGEMENT  SYSTEM. 

1 1  ESTABLISHMENT  OF  A  RESPONSIVE  TRAINING  AND  C3  CM  SUPPORT  CAPABILITY. 

V  --  -  -  -  --  - - - - - - - 

LEVEL  OF  EFFORT _ 

f  APPROXIMATELY  A  75  PERSON  YEAR  EFFORT  OVER  A  PERIOD  OF  3  5  TO  4  YEARS.  1 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND _ 

SYSTEM  ENGINEERING  AND  ANALYSIS.  ALSO  REQUIRES  EXTENSIVE  OPERATIONAL  AND  INTELLIGENCE 
EXPERIENCE. 


lavssscjwruarsrJSTTiasr  - 


TASK  INPUTS/INTERFACES 

f  -  1  — - - -  ~  -  ‘  *  ''  ‘'N 

1.  GREAT  DEPENDENCY  UPON  TOTAL  AIR  FORCE  SUPPORT  WITH  PARTICULAR  EMPHASIS  IN  >  C/IN  AND 
OPERATIONAL  USERS  AREA. 

2.  SUB  l  ASXS,  AS  DEPICTED  IN  VARIOUS  INDIVIDUAL  TASK  SHEETS.  ARE  DEPENDENT  UPON  EACH  OTHER 

3  THIS  EFFORT  WILL  HAVE  GREAT  IMPACT  ON  THE  AUTOMATION  AND  STANDARDIZATION  OF  ECS  SUPPORT 
PROCESSES,  MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITIES.  AND  ECS  SUPPORT  NETWORKS 
INITIATIVES. 


TASK  DELIVERABLES/KEY  MILESTONES 


1.  ESTABLISHMENT  OT  AFLC  ECS  READINESS  CAPABILITIES 
MANAGEMENT  ORGANIZATIONS 
2  DEVELOP  AND  MAINTAIN  A  PRIORITIZED  ECS  READINESS 
SYSTEM/SUBSYSTEM  LISTING 

3.  ECS  READINESS  CONCEPT  OF  OPERATIONS  DEVELOP¬ 
MENT  AND  APPROVAL 

4.  ESTABLISHMENT  OF  AFLC  ECS  INI ELLIGENCE  SUPPORT 
CAPABILITY 

5.  INITIATE  AFLC  INTELLIGENCE  ACCESS  REQUIREMENTS 

6.  OBTAIN  ISS/ISF  THREAT  IMPACT  ANALYSIS  CAPABILITY 

7.  DETERMINE,  REPORT,  AND  STORE  SELECTED  ECS 
READINESS  SYSTEM/SUBSYSTEM/SENSITIVITIES/ 
VULNERABILITIES 

8.  OBTAIN  CAPABILITY  TO  USE  FLIGHT  DATA  IN  ISS/ISF 
0.  ECS  READINESS  ISS/ISF  PREEMPTIVE  ENGINEERING 

CAPABILITY 

10.  ECS  READINESS  CONFIGURATION  MANAGEMENT 
SYSTEM  IDENTIFICATION 

11  RESPONSIVE  TRAINING  AND  C3  CM  CAPABILITY 


1982  1  1983  I  1984  1  1085 


a.— A-— a— a 

AA  A — A 


kdiness  Support:  Overview  and  Summary  Task  Sheet 
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PROJECT 

MANAGEMENT 


IMENT 


«TS^.r 

CAPABILITY 
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THREAT 


ACQUISITION 
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SUBSYSTEM  I 
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FLIGHT  GAT  A  USE 


PREEMPTIVE 

CAPAB*?Trr* 
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INPUT  FROM  RELATED  ACTIVITIES 


MANAGEMENT, 
ENGINEERING,  ACQUISITION, 
AND  SUPPORT  PRACTICES 

•  MANAGEMENT,  DIRECTION 

•  PLANNING 

•  POLICY 

•  GUIDANCE 

•  BUDGET 

•  RESOURCES 


AUTOMAT  :ON  AND 
STANDARDIZATION  OF 
ECS  SUPPORT  PROCESSES 

•  MANAGEMENT  TOOLS 

•  SUPPORT  TOOLS 

•  PROJECT'  TOOL  , 

•  PROCEDURES 

•  OAT  A  BASE 

•  INTERFACE 


- $ 


MODULAR  EXTENDABLE 
INTEGRATION 
SUPPORT  FACILITIES 

•  ARCHITECTURE 

•  SECURITY 

■*  DATAFV.SE 
•-  Simulation 

•  COMMUNICATION 

•  LOCAL  NETWORK. 


ECS  SUPPORT 
NETWORKS 


PROTOCOLS 
SECURITY  . 
TRAFFIC  | 

NETWORK  CONTROI 
PR ’OR  I  TIES  I 

ARCHITECTURE  I 


PROJECT 

MANAGEMENT 


PLANNING 


PROJECT 

RESOURCES 


CONTRACTS 

APPROVAL 


WORKING  GROUP 
PARTICIPATION 


PROGRAM 

REVIEWS 


CAPABILITIES 

INTEGRATIOF 


Figure  5-34.  ECS  ReadineHS  Support:  Proll 


.  . .  p 


TASK  DESCRIPTION  ECS  READINESS  SUPPORT 
SUBTASK  DESCRIPTION  PROJECT  MANAGEMENT 


ECS  SUPPORT 
NETWORKS 


•  PROTOCOLS  | 

•  SECURITY  1 

•  TRAFFIC  i 

•  NETWORK  CONTROL  i 

•  PRIORITIES  I 

o  ARCHITECTURE  ! 


TASK  OBJECTIVES) 


TO  ESTABLISH  A  DE  QIC ATEO  Af  LC  ECS  OVERSIGHT  MANAGEMENT  FUNCTION  'OR  THE  PURPOSE  OF  DIRECT 
ING  ALL  HEADQUARTERS  AFLC  EFFORTS  ASSOCIATED  WITH  THE  ECS  READINESS  ACQUISITION  CAPABILITY 
INITIATIVE.  , 


MAJOR  ISSUES/PROBLEM  AREAS 

f . . . . . . .  . . .  ■  —i  —  . 

1  ECS  READINESS  CAPABILITIES  ACQUISITION  INITIATIVE  IMPACTS  ON  SEVERAL  EXISTING  AFLC/OCS  AND 
ACQUISITION  LOGISTICS  DIVISION  IALDI  AND  ALC  FUNCTIONAL  RESPONSIBILITIES. 

J.  TO  ENSURE  SUCCESS  A  CENTRAL  FOCUS  WITHIN  HO  AFLC  IS  REQUIRED  TO  PULL  THE  VARIOUS  TASKS 
TOGETHER, 

3.  TO  OBTAIN  THE  FULL  ECS  READINESS  CAPABILITY  WITHIN  AFLC  WILL  REQUinE  SEVSPAL  YEARS  OF 
DECTCATEC  EFFORT. 

- — - -  ■  -  -  - - -  > 

T*$K  APPROACH 

1.  EITHER  ESTABLISH  A  NEW  OR  QIVE  MANAGEMENT  OVERSIGHT  RESPONSIBILITIES  TO  AN  EXISTING  AFLC 
ORGANIZATION. 

2.  PROVIDE  THE  NECESSARY  MANPOWER/RESOURCES  TO  ACCOMPLISH  THE  JOB.  (SEE  LEVEL  OF  EFFORT 
I  FOR  DETAILS.) 


CAPABILITIES 

INTEGRATION 


:0ss  Support:  Project  Management 

!■  i  h 


iliilHfcyJiCGCu  .  i'/d&s  ‘iWAIilei , 


LEVEL  OF  EFFORT 

/■• — - -  — -  - . .  •—  - - - 

TO  ACCOMPLISH  TASKS  OUTLINED  WILL  REQUIRE  A  3  PERSON  AFLC  ORGANIZATION  WITH  PERIOD  OF  PER 
FORMANCE  OF  JH  TO  4  YEARS. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


1.  SENIOR  MANAGER  WITH  ENGINEERING  EXPERIENCE.  PREVIOUS  MAJOR  COMMAND  OR  AIR  STAFF  LEVEL 
INTELLIGENCE  EXPERIENCE  IS  EXTREMELY  DESIRABLE. 

2.  TWO  ENGINEERS  WITH  AFLC  EXPERIENCE.  PREVIOUS  INTELLIGENCE  EXPERIENCE  IS  EXTREMELY 
BENEFICIAL. 


TASK  INPUTS/INTERFACES 


1.  CLOSE  COORDINATION  WITH  HO  USAF/LEYY  AND  AF/INYW  IS  ESSENTIAL. 

2.  EFFORTS  IN  THIS  AREA  WILL  IMPACT  ON  THE  AUTOMATION  AND  STANDARDIZATION  OF  ECS  SUPPORT 
PROCESSES,  MODULAR  EXTENDABLE  INTEGRATION  SUI  FORT  FACILITIES.  AND  ECS  SUPPORT  NETWORKS 
INITIATIVES. 


TASK  OELIVERABLES/KEY  MILESTONES  ’*2  1963  1964  1985 


1.  ESTABLISH  AFLC  ORGANIZATION 

2.  REVIEW'REFINE  APPROACH 

3.  INITIATE  EFFORTS 

4.  MONITOR 


innnnnnnn 


OTHER 
SUB  TASK 
INTERFACE 


TASK  DEBCRIPTION. 


TASK  OBJECTIVS(t) 


MAJOR  ISSUES/PROBLEM  AREAS 


ICS  RSADINtBS  SUPPORT 


SUSTASK  ftSSTRimOM  ECS  READINESS  SYSTEM/SUBSYSTEM  LISTING  DEVELOPMENT 


THE  DEVELOPMENT  AND  MAINTENANCE  OF  A  COMPREHENSIVE  PRIORITIZED  LISTING  OF  THOSE  ECS 
SVSTEMS /SUBSYSTEMS  WHICH  SHOULD  IE  INCLUDED  UNDER  THE  READINESS  SUPPORT  CONCEPT. 


I.  CRITERIA  FOR  DETERMINING  ECS  SYSTEMS/SUBSYSTEMS  TO  BE  INCLUDED  UNDER  THIS  CONCEPT  DOES 
NOT  CURRENTLY  EXIST. 


SYSTEMS/SUBSYSTEMS  THAT  HAVE  NOT  HAD  PMRT  ARE  DISPERSED  THROUGHOUT  AFLC. 
SYSTEMS/SUBSYSTEMS  IN  DEVELOPMENT  WITHIN  AFSC  MUST  BE  INCLUDED. 


OPERATIONAL  USER'S  INPUT  IS  REQUIRED  TO:  A)  DEVELOP  CRITERIA  FOR  DETERMINING  ECS  SYSTEMS/ 
SUBSYSTEMS  TO  BE  INCLUDED  UNOER  READINESS  CONCEPT:  AND  B)  DEVELOP  PRIORITIZED  LIST. 


LISTING  MUST  BE  REVIEWED  AND  UPDATED  YEARLY  FOR  USE  IN  POM  CYCLE. 


DATA  BASE  (LISTING!  LOCATION,  SOFTWARE,  HOST  COMPUTER.  AND  RESPONSIBLE  AFLC  AGENCY  ARE 
CURRENTLY  UNIDENTIFIED. 


TASK  APPROACH 


1.  GENERICALLY  IDENTIFY  THE  CHARACTERISTICS  OF  THE  SYSTEM/SUBSYSTEM  ECS  WHICH  QUALIFY 
THEM  FOR  INCLUSION  UNDER  THE  READINESS  SUPPORT  CONCEPT. 

•  ANALYZE  TYPICAL  SYSTEM/SUBSYSTEM  FROM  EACH  ECS  CATEGORY. 

•  SURVEY  OPERATIONAL  USER  COMMANDS  FOR  THEIR  INPUTS. 

•  USE  THESE  CHARACTERISTICS  TO  FACILITATE  ITEM  2. 


2.  REQUEST  INITIAL  LISTING  OF  ECS  SYSTEMS/SUBSYSTEMS  FROM  EACH  ALC. 

3.  THROUGH  ALO  REQUEST  LISTING  OF  ECS  SYSTEMS  UNDER  DEVELOPMENT  WITHIN  AFSC. 

4.  IN  COORDINATION  WITH  OPERATIONAL  USERS.  CONSOLIDATE  AND  APPROVE  A  PRIORITIZED  LISTING 


OF  SYSTEMS/SUBSYSTEMS  WHICH  SHOULD  BE  INCLUDED  UNDER  THE  READINESS  SUPPORT  CONCEPT. 


S.  ON  A  YEARLY  BASIS,  REVIEW,  UPDATE,  AND  REPRIORITIZE  THIS  LIST  FOR  USE  IN  POM  CYCLE 
PREPARATION. 


6.  DESIGNATE  RESPONSIBLE  HEADQUARTERS  AGENCY  FOR  CONSOLIDATION/MAINTAINING  READINESS 
SUPPORT  LISTING  AND  PROVIDING  YEARLY  INPUTS  TO  POM  CYCLE. 


7.  FORMAT  AND  STORE  LISTING  AS  PART  OF  READINESS  SUPPORT  DATA  BASE. 


LEVEL  OF  EFFORT 


APPROXIMATELY  4*  PERSON  YEARS  EFFORT  WITH  RATHER  EXTENSIVE  TRAVEL  TO  OBTAIN  OPERATIONAL 
USERS  AND  AFSC  INPUTS.  LENGTH  OF  EFFORT  SHOULD  BE  A  MINIMUM  OF  24  MONTHS. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


ENGINEER/SYSTEM  ANALYSIS  WITH  A  MINIMUM  OF  SEVEN  171  YEARS  OF  EXPERIENCE  WITH  ECS  AND  THEIR 
OPERATIONAL  USE.  A  FIRM  UNDERSTANDING  OF  AF LC  PROCEDURES  AND  AIR  FORCE  ROLES  AND  MISSIONS 
IS  ESSENTIAL. 


TASK  INPUTS/INTERFACES 


KEY  INPUTS  ARE  REQUIRED  FROM  AFSC,  ALC,  AND  OPERATIONAL  USERS.  INTERFACES  WITH  OPERATIONAL 
USERS  IS  REQUIRED  TO  DETERMINE  CRITERIA  I  ITEM  1  UNDER  MAJOR  ISSUES). 


TASK  DEUVERABLES/KEY  MILESTONES 


MONTHhJZ  3U  SISlTlB  8  10  1.1  12113  14llB  16l!7  18  19 


1.  ECS  REAOINESS  CRITERIA 
DETERMINATION 


2.  SURVEY  ALC  AND  AFSC  FOR  SYSTEMS/ 
SUBSYSTEMS 


3.  INITIAL  LISTING 

4.  LIST  PRIORITIZATION  AND  APPROVAL 
6  DATA  B.iSE  FORMATT'NG 

SDR,  PDR,  COR 


adiness  System/ Subsystem  Listing  Development 


I 


TASK  DESCRIPTION . 


I  REAOINES8  SUPPORT 


SUBTASK  WB^WITIFIM  *CS  READINESS  CONCEPT  OF  OPERATIONS 
TASK  OBJECTIVES) 


ID6HT^)CA  TWH 


TO  OBTAIN  AN  AIR  FORCE  APPROVED  ECS  READINESS  CONCEPT  OF  OPERATIONS  WHICH  CLEAHLY  PARTI¬ 
TIONS  RESPONSIBILITIES  among  the  various  air  force  major  commands  and  special  operating 
I  OC  AT  IONS  AND  ASSIGNS  THE  ASSOCIATED  SPECIFIC  TASKS  REQUIRED  TO  PERFORM  THESE  RESPONSIBIL¬ 
ITIES.  THIS  CONCEPT  OF  OPERATION  WILL  SERVE  AS  THE  AIR  FORCE  AUTHORITATIVE  DOCUMENT  FOR 
RESOURCE  REQUESTS  AMONG  THE  VARIOUS  PARTICIPANTS. 

. .  -  ■  . —  i  —  —  -  -  - ■ 

MAJOH  ISSUES/WtOBLIM  ARIAS _ 

1.  WITH  ONE  EXCEPTION.  THE  OPERATIONAL  USER  IS  LARGELY  UNAWARE  OF  THE  SIGNIFICANCE  AND 
MAGNITUDE  OF  THE  READINESS  SUPPORT  ISSUE  ON  HIS  COMBAT  CAPABILITY.  (THE  ONE  EXCEPTION  IS 
IN  THE  EW  ECS  CATEGORY. | 

2.  SOLUTIONS  TO  THE  PROBLEM  WILL  REQUIRE  COMMITMENT  OF  SIGNIFICANT  AIR  FORCE  RESOURCES 
AMONG  SEVERAL  MAJOR  COMMANDS. 

3.  AIR  STAFF,  OOD  AND  CONGRESSIONAL  SUPPORT  WILL  BE  REQUIRED  FOR  RESOURCES;  HOWEVER.  UNDER- 
STANDING  OF  THE  PROBLEM  AT  THESE  LEVELS  IS  LIMITED. 

4.  DEVELOPMENT  OF  THE  CONCEPT  OF  OPERATIONS  WILL  REQUIRE  AIR  FORCE  WIDE  SUPPORT  SIMILAR  TO 
TH»NT  RCQDIREDTO  DEVELOP  THE  ELECTRONIC  WARFARE  INTEGRATED  REPROGRAMMING  CONCEPT 

(EWIRCI. 


Kg  group 

Kn 


TASK  APPROACH 

/■  —  -  . -  -  —  .  .  . — . . .  . . . 

1.  REQUEST  USAF/LE  1  CHAIR  CONCEPT  OF  OPERATIONS  WORKING  GROUP. 

2.  FROM  USAF/LE  OR  USAF/CV  LEVEL,  REQUEST  MAJOR  COMMAND  AND  AIR  STAFF  SUPPORT. 

3.  ESTABLISH  USAF/LEY  CHAIRED  CONCEPT  OF  OPERATIONS  WORKING  GROUP  (SUGGEST  PREVIOUS  USAF / 
XOA  CHAIRf  :0  ELECTRONIC  WARFARE  INTEGRA!  ED  REPROGRAMMING  CONCEPT  IEWIPCI  WORKING 
GROUP  SERVE  AS  A  BASELINE  APPROACH  FOR  DETERMINING  CONCEPT  OF  OPERATIONS  WORKING  GROUP 
MEMBERS  AND  CHARTER), 

4.  DRAFT  AND  APPROVE  SOW  FOR  CONTRACTOR  SUPPORT  IN  DEVELOPING  CONCEPT  OF  OPERATIONS. 

5.  DETERMINE  AND  TARGET  CONCEPT  OF  OPERATIONS  TOWARD  APPROPRIATE  AIR  FORCE  REGULATION 
FOR  IMPLEMENTATION. 

6.  PREPARE  INITIAL/ORAFT  CONCEPT  OF  OPERATIONS. 

7.  REQUEST  COMMAND  REVIEW  AND  APPROVAL. 

S.  IMPLEMENT  IN  AIR  'ORCE  REGULATIONS. 

-  -  -  ...  -  -  -  -  -  .  — 

LEVEL  OF  EFFORT _ 

AIR  FORCE;  WORKING  GROUP  RESPONSIBli  ITIES  WILL  EXTEND  OVER  APPROXIMATELY  IS  MONTHS.  DUR 
ING  THIS  TIME.  3  TO  4  OHE-WEEK  MEETINGS  WILL  BE  REQUIRED  AND  WILL  INCLUDE  ALL  WORKING  GROUP 
MEMBERS.  TO  PREPARE.  REVIEW,  AND  COORDINATE  DATA,  EACH  PARTICIPATING  COMMAND,  SERVICE. 
CENTER.  AND/OR  OPERATING  LOCATION  MAY  REQUIRE  ONE  DEDICATED  PERSON  FOR  THE  YEAR. 

AIR  FORCE  LEVY  PARTICIPATION  WILL  REQUIRE  ONE  PERSON  FULLTIME  FOF»  THE  18  MONTHS.  OTHER  AIR 
STAFF  PARTICIPANTS  WILL  BE  DEDICATED  FOR  X  OF  THEIR  TIME  FOR  THE  18  MONTHS. 

EXTENSIVE  TD”  Wll  L  BE  NECESSARY  FOR  BOTH  THE  WORKING  GROUP  AND  THE  CONTRACTOR  FOR  DATA 
GATHERING  ANU  COORDINATION  VISITS  EXACT  TOY /VISIT  SCHEDULE  MUST  BE  WORKED  OUT  DURING  SOW 
DRAFTING  ACTION. 

CONTRACTOR.  38  PERSOfi  MONTHS  OF  EFFORT  WILL  BE  REQUIRED  TO  PRFPARS  CONCEPT  OF  OPERATIONS 
OVER  AN  18  MONTH  PERIOD.  THIS  IS  AN  EXTREMELY  TIGHT  SCHEDULE  WITH  SEVERAL  KEY  REVIEWS  ESSEN 
Tl  AL  TO  A  SMOOTH  F  LOW  OF  ACTIVITIES. 

_ - .... — -  ,  .  .  .  . . . 

PERFORMER  EXPERIENCE  LiVtL/BACKOWOONO _ _ _ 

CONTRACTOR:  ENGINEER/SYSTEM  ANALYSIS  WITH  A  MINIMUM  OF  TEN  (10)  YEARS  OF  EXPERIENCE  WITH 
ECS  AND  THEIR  OPERATIONAL  USE,  A  STRONG  UNDERSTANDING  OF  AIR  FORCE  ROLES  AND  MISSIONS  IS 
ESSENTIAL. 


IMPLEMENTATION 

PROCEDURES 


TASK  lNPUTt/»:TER  FACES  _ _ _ 

1.  INPUTS  ARE  REQUIRED  FROM  AF/IN  AND  MAJOR  COMMANDS. 

2.  RAPID  MAJOR  COMMAND  REVIEWS  ARE  ESSENTIAL. 

3.  THIS  EFFORT  WILL  HAVE  AN  IMPACT  ON  THE  MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILI 
TIES  AND  ECS  SUPPORT  NETWORKS  INITIATIVES. 


TASK  OELIVEAABI.es/KEY  MILESTONES 


MONTH)  2|4  |6|B  |10[12|  14|  161 18|20l  2;l24l26|28|30|32|34|36| 


1.  REQUEST  USAF/LEY  SUPPORT  (AFLC) 

2.  USAF/CV  DIRECTION  FOR  SUPPORT 
(USAF/LE) 

3.  FORM  WORKING  GROUP  IUSAF/LEYYI, 
DRAFT  SOW,  DEVELOP  IMPLEMENTATION 
APPROACH,  LET  CONTRACT  (USAF/ 

LEYYI 

4.  DEVELOP  CONCEPT  OF  OPERATIONS; 
REQUIRE  DEFINITION  ANO  DATA 
GATHERING,  FUNCTIONAL  PARTITION¬ 
ING,  REVIEW/APPROVAL  IDENTIFICA¬ 
TION  OF  FUNCTIONAL  RESPONSIBILITY 
BY  AF  ORGANIZATION,  REVIEW/ 
APPROVAL,  RESOURCE  AND  FUND'NG 
PROFILE  DEVELOPMENT,  REVIEW  AND 
APPROVAL,  FINAL  REPORT /CONCEPT 
PREPARATION,  AF  REVIEW,  FINAL 
PUBLICATION 

6  IMPLEMENTATION  IN  AF 
REGULATIONS  IUSAF/LEYYI 

SDR.  FOR,  CDR 


pt:  ECS  Readiness  Concept  of  Operations 
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Figure  5-37,  ECS  Readiness  Support:  ECS 
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TASK  DESCRIPTION  „ 
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SJBTASK  nEKCRiPTiON  ecs  inte lligfnce  support  cabability 


TASK  OBJECTIVE(S) 


OBTAIN  THE  CAPABILITY  AND  RESOUF.CES  NECESSARY  TO  RECEIVE.  STORE.  PRODUCE  AND  ANALYZE 
SYSTEM/SUBS  VST  EM  RELATED  CLASSIFIED  INTELLIGENCE  DATA. 


MAJOR  ISSUE  S/PRO  SLIM  AREAS 


1  IMPACTS  THE  AFLC  ORGANIZATION  IN  THAT  MANPOWER  TO  SUPPORT  THIS  FUNCTION  MUST  COME  FROM 
WITHIN  AFLC  IAFR  200-1). 

2.  SPECIAL  ACCESS  REQUIREMENTS  WILL  REQUIRE  AF/IN  SUPPORT. 

3.  LIMITED  PRE  /lOUS  AFLC  EXPERIENCE  IN  THIS  AREA  WITH  IMPLICATIONS  IN:  TRAINING,  PERSONNEL 
IDENTIFICATION  DATA  IDENTIFICATION/ACQUISITION.  COMMUNICATION  REQUIREMENTS,  FACILITY 
SPECIFICATION,  AND  INTELLIGENCE  PROCESS. 

4.  AF/IN.  OPERATIONAL  USER.  AND  AlR  STAFF  SUPPORT  ESSENTIAL  FOR  oUCCESS  COMPLICATING  THE 
ISSUE  IS  THE  PROBLEM  OF  LIMITED  UNDERSTANDING  OF  THE  AFLC  ECS  READINESS  ISSUE  BY  THESE 
ORGANIZATIONS 


TASK  APPROACH 


1.  INITIATE  EDUCATIONAL  DIALOCUE  WITH  AF/IN.  OPERATIONAL  USER.  AND  AIR  STAFF. 

2.  REQUEST  FORMAT  AF/lN  SUPPORT  IN  ESTABLISHING  AFLC  INTELLIGENCE  CAPABILITY. 

3  ESTABLISH  AFLC  CHAIRED  WORiCING  GROUP  TO  PREPARE  DETAILED  ROAD  MAP  FOR  OBTAINING  AFLC 
INTELLIGENCE  SUPPORT  ORGANIZATION 

A.  WORKING  GROUP  MEMBERS  SHOULD  INCLUDE;  HO/AFLC  ICHAIRMAN),  ALC,  HO  USAF/IN/LE,  ALD, 
MPC,  FTO.  AFSC.  COMMUNICATIONS  COMMAND.  AND  USER. 

6.  CHARTER 

•  FORMULATE  RECOMMENDED  AFLC  INTELLIGENCE  ORGANP2AT  iONAL  STRUCTURE  TO  INCLUDE. 
HQ  AF  LC/IN  STRENGTH.  FUN  .  IONAL  REPORTING  CHAIN  AND  MISSION;  ALC/IN  STAFF.  LOCATION, 
REPORTING  CHAIN  AND  MISSION;  INITIATE  AFLC  SPECIAL  ACCESS  CLEARANCE  REQUIREMENTS; 
ISSUE  OFFICIAL  ALC  TASKING  FOR  SUPPORT  IN  SELECTED  AREA;  FACILITY  DEVELOPMENT  PLAN. 
AND  AFLC  RESOURCE  IMPACT,  FUNDING  PROFILE.  AND  MANPOWER  REQUISITION  REQUIREMENTS. 

•  PROVIDE  RECOMMENDATIONS  TO  APPROPRIATE  HO  AFLC  ORGANIZATION  FOR  IMPLEMENTATION. 
RECOMMEND  "TWO*'  LETTER  SYMBOL.  ALSO  RECOMMENDATIONS  SHOULD  BE  BRIEFED  TO  AF/IN. 
HO  USAF/LE/XO/RD/MP.  AND  USERS. 


LEVEL  OF  EFFORT 


THIS  IS  PRIMARILY  AN  INTERNAL  AFLC  ADMINISTRATIVE  ACTION  WITH  SUPPORT  FROM  OTHER  AIR  FORCE 
AGENCIES;  HOWEVER.  A  DEDICATED  AFLC  STAFF  WILL  BE  REQUIRED  TO  PERFORM  THE  NECESSARY  FUNC¬ 
TIONS  RECOMMEND  A  DEDICATED  TWO  PERSON  EFFORT  WITH  APPROPRIATE  ADMINISTRATIVE  SUPPORT 
FOR  APPROXIMATELY  1  YEAR  TO  10  MONTHS.  FURTHER  RECOMMEND  THIS  TWO  PERSON  EFFORT  BE 
HEADED  BY  AN  05  OR  GS-13  TO  SUPPORT  THIS  EFFORT,  AFLC  SHOULD  CONSIOER  THE  SERVICES  0?  A 
“QUALIFIED"  CONSULTANT  FQRTHE  DURATION  OF  THE  EFFORT.  AS  TOY  WILL  BE  NECESSARY.  AN  APPRO 
PRIATE  BUDGET  SHOULD  BE  ESTABLISHED. 


PERFORMER  EXPERIENCE  LSVEL/BACKGROUND 


FOR  AFLC  STAFF,  RECOMMEND  TELECTION  OF  PER.. ONNEL  WITH  PREVIOUS  EW  AND  MAJOR  COMMAND 
INTELLIGENCE  EXPERIENCE  PERSONNE L  WITH  PREVIOUS  AF.'INYW,  AFIS  OL-N/OL-F,  AND  AFEWC  EXPERI 
ENCE  SHOULD  RANK  HIGH  IN  THE  SELECTION  GROUP  iN  ADDITION.  LEAD  PERSONNEL  SHOULD  HAVE 
STRONG  MANAGEMENT  AND  ORGANIZATIONAL  EXPERIENCE. 


TASK  INPUTS/INTERFACIS 


WORKING  GROUP  INPUTS  ARE  ESSENTIAL.  AF/IN  SUPPORT  NECESSARY  TO  ESTABLISH  CAPABILITY. 


TASK  DELIVERABLES/KEY  MILESTONES 


MONTH  14  15  16  1718  19  20 


1.  ESTABLISH  AFLC  STAFF 

2.  PREPARE  BRIEFINGS  FOR  AF/IN.  USERS. 
AIR  STAFF 

3.  FORMULATE  WORKING 

4.  GROUP  CHARTER 

5.  BRIEF  AND  REQUEST  SUPPORT 

6.  CONTRACT  FOR  CONSULTANT 

7.  WORKING  GROUP  MEETINGS 

8.  INITIATE  ACTIONS  REQUESTING 
FORMATION  OF  HQ/AFLC  AND  ALC 
STAFFS 

9.  INITIATE  REQUESTS  FOR  CLEARANCES, 
FACILITIES,  AND  COMMUNICATIONS 


^rt:  ECS  Intelligence  Support  Capability 


?7T«/ff  s^-yxcret-  'p-xin^  .-. .  -•.--/. 

Trii  -intt'rr- *4  ’iw&fiiHMBantMjl/W ' ' '  =ffS] 
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TASK  DESCRIPTION. 


teg  READINESS  SUPPORT 


SUIT  ASK  MBWWIBTIflAI  INTELLIGENCE  ACCESS  PEQU:REMENTS 

TASK  ORJICTIVIIS) 


e 


TO  OBTAIN  SPECIAL  INTELLIGENCE  BILLETS,  CLEARANCES,  AND  ACCESS  FOR  THE  REQUIRED  AFLC  PERSON 
NEL  AND  CONTRACTORS, 


MAJOR  ISSUES/PROILEM  ARIAS 


1.  SPECIAL  ACCESS  CLEARANCES  ARE  CONTROLLED  BY  AF/IN. 

2.  A  CEILING  IS  PLACED  ON  THE  AIR  FORCE  AS  TO  THE  TOTAL  NUMBER  OF  SPECIAL  ACCESS  BILLETS 
AUTHORIZED. 

J.  NORMALLY  THE  RESPONSE  FOR  ADDITIONAL  "BILLETS"  IS  TO  DIRECT  THE  REQUESTING  COMMAND  TO 
REALIGN  THEIR  EXISTING  BILLET  STRUCTURE 

4.  REAOINESS  ISSUE  MAY  NECESSITATE  AIR  FORCE  REQUEST  FOR  ADDITIONAL  "BILLETS"  FROM  THE  CON 
TROLLINQ  NATIONAL  AGENCY. 

5.  ADEQUATE  “BILLET"  JUSTIFICATIONS  ARE  VERY  DIFFICULT  TO  PREPARE  WITHOU'i  PREVIOUS 
EXPERIENCE. 

fl.  AFLC  PERSONNEL/JOB  DESCRIPTION  REQUIRING  SPECIAL  ACCESS,  UNDER  THE  READINESS  PROGRAM, 
HAVE  NOT  BEEN  IDENTIFIED. 


TASK  APPROACH 


t.  REQUEST  AF/IN  SUFPORT. 

2.  BASED  UPON  "NEED  TO  KNOW."  IDENTIFY  AFLC  ACCESS  REQUIREMENTS  BY: 

A  JOB  POSITION. 

~  LEVEL  of  CLEARANCE  required. 

3.  CONSOLIDATE,  REVIEW,  AND  OBTAIN  AFLC  APPROVAL  OF  TASK  ITEM  2.  ABOVE 

4.  COORDINATE  TASK  ITEM  2.  AND  OBTAIN  GUIDANCE  FROM  AF/!.*I. 

B.  PREFARE  WRITTEN  JUSTIFICATION  AND  FORWARD  TO  AF/IN  FOR  ACTION. 


LEVEL  OP  EFFORT 

THIS  WILL  BE  A  DAY-TO-DAY  JOB  FOR  THE  AFLC  INTELLIGENCE  STAFF,  HOWEVER.  INITIALLY  IT  WILL 
REQUIRE  A  DEDICATED  S  MONTHS  TO  1  YEAR 

PERFORMER  EXPERIENCE  LEVS  L/EACKO  ROUND 

CLASSIC  INTELLIGENCE  AIR  FORCE  SPECIALTY  COOES  IAFSCI. 

TASK  INPUTS/INTERPACII 

1  AF/IN  SUPPORT  IS  ESSENTIAL 

2.  ALC  MUST  DEVELOP  RECOMMENDED  PERSONNEL/ JOB  TITLC  LIST. 

3.  ALC  MUST  PREPARE  WRITTEN  BILLET  JUSTIFICATION. 

TASK  DEUVERAaLES/KSV  Ml  LISTONS  A 

1983 

1984 

month 


1.  REQUEST  AF/IN  SUPPORT 

2.  REQUEST  ALC  BILLET  LIST  ALONG  WiTH 
JUSTIFICATION 

3.  REVIEW,  CONSOLIDATE  AFLC  ACCESS 
LIST 

4.  OBTAIN  AFLC  COMMENTS  ON  REVISED 
ACCESS  LIST 

5.  REQUEST  AF/IN  REVIEW  AND 
COMMENTS 

6.  PREPARE,  COORDINATE  LIST  AND 
JUSTIFICATION 

7.  SUBMIT  FOR  AF/IN  ACTION 


A 


jjBupport:  Intelligence  Access  Requirements 
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Figure  5-39.  ECS  Readiness  Support:  ISS/ISF  Threat  A 
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TASK  DEBCRIFTION . 


ECS  READINESS  SUPPORT 
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SUBTASK  DESCRIPTION  ISS/ISF  THREAT  ANALYSIS  CABABlLITY  ACQUISITION 

TASK  OBJECTIVE!*) 


TO  ESTABLISH  THE  CAPABt  LIT  V,  Wll  HIN  EACH  .SS/»SF.  TO  DETERMINE  THE  IMPACT  OF  THE  ACTUAL  OR 
SUSPECTED  THREAT  ON  SELECTED  5YSTEM/SUBSYSTEM  ECS  SOFTWARE. 


MAJOR  tSSUCS/PftOBLf M  ARIAS 


1.  THE  ECS  CHANCE/MODlFICAT  .CN  RESPONSE  TIME  IS  A  KEY  FACTOR  IN  DETERMINING  THE  VARIOUS 

SYSTEM/SUBS  VS1  EM  ISS/IST  RE  ADINESS  SUPPORT  CAPABILITY  AND  THE  MODIFICATION  REQUIRED  WITH 
THE  EXCEPTION  OF  THE  IW  CATEGORY.  THIS  CHANGE /MODIFICATION  RESPONSE  TIME  REQUIREMENT 
HAS  NEVER  BE  F.N  DETERMINED 

2  OPERATIONAL  USER’S  SUPPORT  IS  REQUIRED  TO  DETERMINE  CHANGE/MOOIFICATlON  RESPONSE  TIME. 

3  VARIOUS  STIMULUS  DEVICES/APPROACHES  ARE  CURRENTLY  AVAILABLE  WITHIN  THE.AIR  FORCE 

4  V  ALIDATED/STANDARO  THREAT  OATA  IS  REQUIRED  TO  SUPPORT  THE  STIMULUS  OFVICES  USED  IN  THESE 
ISS/ISF 


TASK  APPROACH 


1  »NG  the  APPROVED  SYSTEM/SU8SYSTEM  ECS  READINESS  LIST  DEVELOPED  UNDER  TASK  2.  OBTAIN 
OPERATIONAL  USERS  RESPONSE/MODIFICATION  TIME  REQUIREMENTS.  USE  THIS  OATA  TO  DEVELOP 
SYSTEM/SUBSYSTEM  RESPONSE/MODIFlCATlON  TIME  REQUIREMENT. 

3  USING  THE  APPROVED  SYSTEM/SUBSYSTEM  ECS  READINESS  L*ST  FROM  TASK  2,  AND  IN  CONJUNCTION 
WITH  OPERATIONAL  USER  AND  AF/IN.  DETERMINE  THREAT  STIMULUS  REQUIREMENTS  FOR  THE  VARI- 
OUi  SYSTEM, ‘SUBSYSTEMS. 

3  SURVEY  EXISTING  AIR  FORCE  STIMULUS  DEVICES.  WITH  PARTICULAR  ATTENTION  GIVEN  TO  DLQ-3B  AND 
EWCLS.  TO  DETERMINE  THEIR  CAPABILITY  TO  SUPPORT  THE  REQUIREMENTS  iN  ITEM  2. 

4.  USING  2  AND  i  DEVELOP  THE  SPECULATIONS  FOR  DEVELOPMENT 'MODIFICATION  REQUIRED  TO 
OBTAIN  THE  STIMULUS  OEVICE(S). 

5.  REQUEST  AF/INE  SUP/*  3RT  IN  PROVIDING  VALIDATED  THREAT  ENVIRONMENTAL  OATA  REQUIRED  TO 
SUPPORT  4 

f  CONCURRENT  WITH  3  AND  4.  OEVfcLOP  SPECIFIC*^.  NS  FOR  ISS/ISF  MODlF iCATlONS  NECESSARY  TO 
ACCOMMODATE  THE  PROPOSED  STIMULUS  INPU  l  THESE  SPECIFICATIONS  SHOULD  INCLUDE 
CONSIDERATION  OF  TASK  8  EFFORT  ALSO  AND  .  jJLD  8E  DEVELOPED  TO  ACCOMMODATE  RQTH  SETS 
OF  REQUIREMENTS  ! 

7.  REQUEST  AFSC  TO  INCLUDE  STIMULUS  DEVICES  DEVELOPED/MODIFIED  IN  4  IN  THE  Al>2  FORCE  SIMULA¬ 
TOR  VALIDATION  EFFORTS. 


LEVEL  OF  EFFORT 


[  1.  32  PERSON  MONTH  EFFORT  OVER  A  12  NTH  PERIOD. 


PERFORMER  EXPERIENCE  LIVE L/BACKGROUND 


ENGINECR/SYSTEM  ANALYSIS  WITH  A  MINIMUM  OF  TEN  (10)  YEARS  EXPERIENCE  WORKING  WITH  SYSTEM 
DESIGN  AND  REQUIREMENT  DETiNITIONS. 


TASK  INPUTS/INTERFACES 


1  TASK  2  IS  CRITICAL  TO  THIS  EFFORT. 

1.  AF/IN  AND  OPERATIONAL  USER  SUPPORT  IS  ESSENTIAL.  RECOMMEND  AFLC  "TWO  LETTER'  MESSAGE 
Re  QUEST  FOR  SUPPORT. 

3.  ASD  SIMULATION  PO  IS  «  KEY  PLAYER  IN  BOTH  POM  SUPPORT  AND  DEVELOPMENT  AREAS. 

4  VALIDATED  THREAT  DATA  FOR  USE  IN  THIS  EFFORT  (BOTH  DEVELOPMENT  AND  DURING  OPERATIONAL 
USE)  IS  A  CRITICAL  AREA  THAT  SHOULD  BE  UNDERSTOOD  "UP  FRONT."  THE  ANSWERS  IN  THIS  AREA 
COULD  HAVE  SERIOUS  IMPACTS  ON  TASK  4.  SPECIFIC  QUESTIONS  WHICH  MUST  BE  ANSWERED  ARE  WHAT 
AGENCY  WILL  DEVELOP  THE  OATA?  WHAT  PROCEDURE  WILL  BE  USED  TO  OBTAIN  AF/IN  APPROVAL' 
REVIEW  OF  DATA?  HOW  MUCH  LEAD  TiME  IS  REQUIRED  FOR  AF/IN  APPROVAL/REVIEW?  ASSUMING  AFLC 
ACCOMPLISHES  DEVELOPMENT  OF  THE  DATA.  WHAT  IS  THE  IMPACT  IN  LIGHT  OF  3  ASK  4  AND  WHAT  ARE 
THE  RESOURCES  REQUIRED? 

-  -  -  —  -  ' 

TASK  DELIVERABLES/KEY  MILESTONES  1983  1984 


MONTH  H  1  2|3|4l5|6l  718191 101 11M2h3|l4hSl  161 17|181 19 


1.  DEVELO®  SYSTEM/SUBSYSTcM 
RESPONSE/MODIC ICATION  TIME 
REQUIREMENT  LISTING 

2.  DEVELOP  THREAD  STIMULUS 
REQUIREMENTS 

3  SURVEY  EXISTING  A;R  FORCE 
STIMULUS  DEVICEF  AND 
DOCUMENT  CAPABILITIES/ 
LIMITATIONS 

4.  DEVELOP  STIMULUS 
SPECIFICATIONS 

5  REQUEST  SIMULATOR  PO 
SUPPORT 

j  f  REQUEST  AF/IN  SUPPORT 

7.  REQUEST  INCLUS'ON  UNDER 
SIMULATION  VAU  MTION 
PROGRAM 

SOR.  PDR,  CDR 


ft  ISS/ISF  Threat  Analysis  Capability  Acquisition 


_ A., 


.......  -  .-  t-  >.■ 


A-yrRC1?' 


TASK  DESCRIPTION. 


tcs  READINESS  SUPPORT 


SUBTASK  DESCRIPTION  8YSTEM/SU0SVSTEM  SENSITIVITIES/VULNERABILITIES  STUDIES 

TASK  OBJECTIVE^) 


SYSTEM/SU3SYSTEM  SENSITIVITIES  STUDIES  TO:  1l  DETERMINE  vulnerabilities  to  actual/expected/ 
POSSIBLE  ADVERSARY  THREAT;  2)  IDENTIFY  GENERIC  ECS  SOFTWARE  MODIFICATIONS  TO  COUNTER  1)  AND 
3)  IDENTIFY  INTELLIGENCE  COLLECTION  AND  ANALYSIS  REQUIRED  TO  SUPPORT  CONTINUING  EFFORTAND 
GUARD  AGAINST  ADVERSARY  TECHNOLOGY 


MAJOR  ISSUES/PROBLEM  AREAS 


1  ISSUE:  IDENTIFICATION  OF  SYSTEMS/SUBSYSTEMS  TO  BE  SUBJECTED  TO  SENSITIVITY  STUDIES 

2.  ISSUE:  IDENTIFICATION  OF  RELATED/PREVIOUS  EFFORTS  IN  THIS  AREA. 

3  PROBLEM:  FUNDING  AND  PROGRAM  MONITOR  PROGRAM  MONITOR  IS  PROBABLY  AT  THE  SYSTEM/ 
SUBSYSTEM  LEVEL. 

4  EFFORTS  MUST  RUN  CONCURRENT  WITH  OTHER  ECS  READINESS  ACQUISITION  TASKS 

S.  JUSTIFICATION  OF  SPECIAL  INTELLIGENCE  CLEARANCES  FOR  CONTRACTOR  AND  AIR  FORCE  PERSONNEL 
THESE  ARE  ABOVE  AND  BEYOND  THOSE  DESCRIBED  IN  TASK  5. 


TASK  APPROACH 

— - - - — — — — — * - - — - — — __ _ 

1.  IDENTIFY  SYSTEMS/SUBSYSTEMS  TO  BE  SUBJECTED  TO  STUDIES.  TASK  2  IS  KEY  INPUT 

2.  ASSIGN  CONTRACT  MONITORS  AT  SYSTEM/SUBSYSTEM  MANAGER  LEVEL. 

3.  IDENTIFY  SOURCES  OF  RELATED/PREVIOUS  WORK  SUCH  AS;  AF/IN  THREAT  ESTIMATES  FOR  SYSTEMS/ 
SUBSYSTEMS,  PROGRAM  OFFICE  WORK.  AFTEC  TESTING.  AIR  FORCE  ELECTRONIC  WARFARE  CENTER 
WORK,  AND  DT&E  F  LIGHT  TEST  REPORTS. 

4.  DRAFT  SOW  AND  INSURE  HEADQUARTERS  OVERSIGHT  TO  MINIMIZE  DUPLICATIONS  AND  INSURE  STU¬ 
DIES  ARE  SUPPORTIVE  AND  REQUEST  SIMILAR  ACTIONS/DELIVERABLES 

5.  FOR  SYSTEMS/SUBSYSTEMS  IN  DEVELOPMENT  CYCLE.  REQUEST  PO  TO  PROVIDE  SENSITIVITY/ 
VULNERABILITY  ASSESSMENT  AT  PMRT. 

6  AT  HQ  USAF/LE  LEVEL,  INITIATE  ACTIONS  TO  INSURE  THAT  FUTURE  PMD’S  REQUIRE  SENSITIVITY  ANAL¬ 
YSIS  AS  PART  OF  DEVELOPMENT  PROCESS. 

7  REVIEW  AND  MODIFY  AS  APPROPRIATE  800  SERIES  AF  REGULATIONS.  IOENTIFY  ISSUE  WITHIN  CRWG 
STRUCTURE  AND  REQUEST  APPROPRIATE  SUPPORT. 

8.  REVIEW  AF  IMPLEMENTATION  OF  DOD  DIRECTIVES  5000.1.  5000.2,  C-4600.3,  4600-4  AND  3100  9  FOR  APPLI¬ 
CABILITY  AND  REQUEST  MODIFICATIONS  AS  REQUIRED. 

9.  REQUEST  AF/IN  APPROVAL  OF  APPROPRIATE  INTELLIGENCE  ACCESS  FOR  CONTRACTOR  PERSONNEL  OR 
REQUIRE  ACCESS  AS  PART  OF  SOW. 


ITASK 


LEVEL  OF  EFFORT _ 

’  LEVEL  OF  EFFORT  WILL  VARY  FROM  SYSTEM/SUBSYSTEM  TO  SYSTEM/SUBSYSTEM.  FOR  INITIAL  FUNDING 
PLANNING  PURPOSES,  SUGGEST  AN  AVERAGE  OF  2  PERSON  YEARS  PER  SYSTEM/SUBSYSTEM  SELECTED 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

P*  -  1  ■  1  1  . — -  -  •  ~  — ~  —  ■ 

ENGINEER/SYSTEM  ANALYSIS  WITH  A  MINIMUM  OF  10  YEARS  IN  SYSTEM/SUBSYSTEM  RELE ATED  AREA. 
ENGINEER/INTELLIGENCE  ANALYSIS  WITH  A  MINIMUM  OF  5  YEARS  IN  TECHNICAL  THREAT  ANALYSIS. 

ALL  PERSONNEL  WILL  REQUIRE  SPECIAL  INTELLIGENCE  CLEARANCES. 

_ _ _ _ _ _ 

TASK  INPUTS/INTERFACES 

- - — - - - ■ - « - - 

1.  SYSTEMS/SUBSYSTEMS  SELECTED  WILL  BE  DETERMINED  USING  ECS  READINESS  PRI0RITI2ED  LIST  FROM 
FROM  TASK  1. 

2.  PREVIOUS  STUDIES/WORK  IS  VERY  IMPORTANT  INPUT  TO  THIS  EFFORT.  SEE  TASK  APPROACH  ITEM  3. 

3  AF/IN,  NATIONAL  INTELLIGENCE  AGENCIES.  AND  OPERATIONAL  USERS  COULO  PROVIDE  VALUABLE 
INSIGHT  INTO  CURRENT /PROJECTED  THREAT  DATA. 

V _ _ _ _ 

TASK  DELIVER  ABIES/KEY  MILESTONES  1982-  1984 


MONTH)  1|2|3|4|5|6|7|8|9|  10|l  l|  t  .  j  13[  14|  15|  16l  1  7|  18l  191  20|  21 1  22 1 


1.  OATA  GATHERING  OF  PREVIOUS 
STUDIES/WORK 

2.  INITIAL  THREAT  ESTIMATE 
CURRENT/PROJECTED 

3.  SYSTEM/SUBSYSTEM  SENSITIVITY 
ANALYSIS* 

4.  ECS  ALTERNATIVES 
IDENTIFICATION 

6.  INTELLIGENCE  COLLECTION/ 
ANALYSIS  REQUIREMENTS 
6.  FINAL  REPO* i 
SDR.  PDR,  CDR 


•THESE  ARE  REPRESENTATIVE  DELIVERABLES/MILESTONES.  ACTUAL  DATA  W'LL  VARY  FROM 
SYSTEM/SUBSYSTEM  TO  SYSTEM/SUBSYSTEM. 


>eystem  Sensitivities/ Vulnerabilities  Studies 


TASK  DESCRIPTION  ECS  READINESS  8UPPORT _ 

81IBTASK  DESCRIPTION  FLIGHT  DATA  USE  IN  ISS/ISF _ ^ 

TASK  OBJECTIVE(S) 

TO  OBTAIN  THE  CAPABILITY  TO  RECORD  ECS  FLIGHT  PERFORMANCE  DATA  UNDER  ACTUAL  THREAT 
RANGE  ENVIRONMENTS,  AND  TO  USE  THIS  DATA  WITHIN  AN  ISS/ISF  TO  ASSIST  IN  DETERMINING  SYSTEM/ 
SUBSYSTEM  OPERATION. 


lOCNTtriCATON 


pHlI 


MAJOR  ISSUES/PROBLEM  AREAS 

1.  VARIOUS  FLIGHT  DATA  RECORDING  CAPABILITIES  ARE  AVAILABLE. 

2.  SPECIAL  DATA  REDUCTION  CAPABILITIES  MUST  BE  OBTAINED  IN  ORDER  TO  USE  DATA  IN  THE  ISS/ISF. 

3.  ADVANCE  DEVELOPMENT  EFFORTS  MAY  BE  NECESSARY  IN  ORDER  TO  OBTAIN  THE  NECESSARY 
CAPABILITIES. 

4.  RANGE  SIMULATIONS  VARY  FROM  RANGE  TO  RANGE  AND  FROM  SYSTEM  TO  SYSTEM.  AS  A  RESULT, 
CAUTION  MUST  BE  EXERCISED  WHEN  THIS  DATA  IS  TO  BE  USE?  TASK  2  AMPLIFIES  IN  THIS  AREA. 

B.  AFLC  MUST  BECOME  AN  ACTIVE  MEMBER  OF  THE  AIR  FORCE  SIMULATOR  VALIDATION  PROGRAM  AND 
PROVIDE  INPUTS  ON  SIMULATOR  VALIDATION  PRIORITIES 
6  OUT  OF  DATE  OR  INACCURATE  SIMULATORS  ARE  CURRENTLY  IN  USE  ON  MANY  OF  THE  AIR  FORCE 
RANGES.  SEE  TASK  2  FOR  ADDITIONAL  INFORMATION. 

TASK  APPROACH _ 

1.  REOUEST  ASD  TO  CONDUCT  ECS  DATA  RECORDING  AND  DATA  REDUCTION  FEASIBILITY  STUDY.  STUDY 
OBJECTIVES  SHOULD  BE  TO: 

A.  IDENTIFY  SPECIFIC  ECS  DATA  WHICH  SHOULD  BE  RECORDED  TO  SUPPORT  THIS  ACTIVITY.  (MEMORY 
AND  REGISTER  ARE  PRIME  EXAMPLES). 

B.  EQUIPMENT  DEFINITION  AND  COST  ESTIMATES. 

C.  RECOMMEND  ACQUISITION  APPROACH. 

O.  COMPLEXITY  OF  RETROFITTING  SUCH  A  CAPABILITY  TO  TASK  2  SYSTEMS/SUBSYSTEMS  -  LIST  HOST 
AIRCRAFT. 

E.  RECOMMEND  DATA  REDUCTION  CAPABILITIES  TO  SUPPORT  ISS/ISF  USAGE  OF  INFORMATION. 

2.  IN  THE  INTERIM,  INITIATE  ACTIONS  AT  THE  SYSTEM/SUBSYSTEM  MANAGER  LEVEL  TO  INSTALL  CUR¬ 
RENTLY  AVAILABLE  FLIGHT  DATA  RECORDING  AND  DATA  REDUCTION  EQUIPMENT  ABOARD  KEY 
AIRCRAFT. 

3.  INITIATE  ACTIONS  TO  MODIFY  EXISTING  ISS/ISF  IN  RESPONSE  TO  2. 


LEVEL  OF  EFFORT _  , _ 

CONTRACTOR:  17  PERSON  MONTHS  OF  EFFORT  OVER  9  MONTH  PERIOD.  THIS  DOES  NOT  INCLUDE  FEASI 
BILITY  STUDY  REQUESTED  FROM  ASD.  ESTIMATE  24  PERSON  MONTHS  IN  THAT  AREA. 

AFLC:  6  PERSON  MONTHS  OF  DEDICATED  EFFORT.  THIS  DOES  NOT  INCLUDE  CONTRACT  MONITOR  RESPON¬ 
SIBILITIES. 

ONCE  FEASIBILITY  STUDY  IS  COMPLETED,  ESTIMATE  3  PERSON  MONTHS  EFFORT  TO  CONVERT  THIS  INTO 
DEFINITIVE  DEVELOPMENT  REQUIREMENTS. 

■  _ . 

PERFORMER  EXPERIENCE  LEVEL/BACKGROUND _ 

ENGINEER/SYSTEM  ANALYSIS  WITH  MINIMUM  OF  7  YEARS  OF  EXPERIENCE.  PERSONNEL  SELECTED  SHOULD  1 
HAVE  PREVIOUS  REQUIREMENTS  AND  SYSTEM  DESIGN  EXPERIENCE  WITH  DTBE/OTRE  BACKGROUND.  | 


TASK  INPUTS/INTERFACES _ 

1.  TASK  2  LISTING  IS  A  KEY  INPUT. 

2.  FORMAL  SUPPORT  FROM  ASD  IS  REQUIRED  IN  AREA  OF  ECS  DATA  RECORDING  AND  DATA  REDUCTION 
ANALYSIS  CAPABILITY  DEVELOPMENT. 

3.  AIR  FORCE  SIMULATOR  VALIDATION  PROGRAM  PRIORITIES  GIVEN  TO  THE  VARIOUS  SIMULATORS  FOR 
VALIDATION  BECOMES  VERY  IMPORTANT  TO  THE  SUCCESS  OF  THIS  EFFORT. 

V  -  —  — 

TASK  DEUVERABLE8/KEV  MILESTONES  '®«2  1883  196 


MONTH!  M2l3|4lsl8l?l8|9ho|n|  12h3h4|l5|l6h7|1Bh9|20| 


1.  REQUEST  ASD  SUPPORT  FOR 
FEASIBILITY  STUDY  (AFLC) 

2.  DEFINE  DATA  RECORDING  AND 
DATA  REDUCTION  ANALYSIS 
CAPABILITY  ON  KEY  AIRCRAFT 

•  KEY  IDENTIFICATION 

•  DATA  RECORDING  REQUIRE¬ 
MENTS  DEFINITION 

•  DATA  REDUCTION  ANALYSIS 
DEFINITION 

•  A/C  RETROFIT  REQUIRE¬ 
MENTS  DEFINITION  AND 
SCHEDULE 

•  FUNDING  PROFILE  AND 
SOURCE  (AFLC) 

3.  SIMULATION  VALIDATION 
INPUTS 

4.  RAD  REQUIREMENTS 


‘Flight  Data  Use  in  ISS/ISF 
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TASK  DESCRIPTION _ ECS  READINESS  support _ 

SUBTASK  nPsrwiPTtON  preemptive  engineering  capability 
TASK  OBJECTIVES! 


to  develop  an  air  force  approved  and  funded 

CAPABILITY. 


ECS  READINESS  ISS/ISF  PREEMPTIVE  ENGINEERING 


MAJOR  ISSUES/PROBLEM  AREAS 


t.  AIR  FORCE  APPROVED  PREEMPTIVE  ENGINEERING  CONCEPT  OF  OPERATIONS  DOES  NOT  EXlST 

2.  UNIQUE  FUN0ING  SOURCES  AND  JUSTIFICATION  WILL  BE  REQUIRED  TO  SUPPORT  THIS  ACTIVITY. 

3.  THE  PREEMPTIVE  ENGINEERING  APPROACH  IS  NOT  WELL  UNDERSTOOD  WITHIN  DOD  OR  CONGRESS 
THEREFORE,  SPECIAL  ATTENTION  MUST  EE  GIVEN  TO  EDUCATION  IN  THIS  AREA. 


TASK  APPROACH 


1.  REOUEST  HQ  USAF/LEYY  SUPPORT  IN  DEVELOPMENT  OF  AN  APPROVED  ECS  READINESS  PREEMPTIVE 
ENGINEERING  CONCEPT  OF  OPERATIONS.  SPECIFIC  SUPPORT  WILL  BE  REQUIRED  IN  AREAS  OF: 

A  OBTAINING  AIR  FORCE  APPROVAL  OF  CONCEPT  OF  OPERATIONS. 

B  DEVELOPMENT  OF  FUNDING  SOURCES  AND  THE  ASSOCIATED  JUSTIFICATION. 

C.  IMPLEMENTATION  IN  AIR  FORCE  REGULATIONS. 

0.  PROVIDING  EOUCATIONAL  BRIEFINGS  AND  DISCUSSIONS  WITH  DOD.  JSC.  AND  CONGRESS. 

2.  REQUEST  WORKING  GROUP  DEVELOPED  UNDER  TASK  4  TO  ASSIST  IN  DEFINING  SOW  FOR  AN  ECS 
READINESS  PREEMPTIVE  ENGINEERING  FEASIBILITY  STUDY.  PURPOSE  OF  STUDY  WOULD  BE  TO 

A.  DETERMINE  SYSTEMS/SUBSYSTEMS/ECS  CATEGORIES  TO  BE  INCLUDED  UNDER  PREEMPTIVE  ENGI¬ 
NEERING  CONCEPT. 

B.  REVIEW  AND  PROVIDE  INPUTS  INTO  TASK  7  SENSITIVITY  STUDIES  OBJECTIVES 

C.  DATA  GATHERING  AND  REQUIREMENTS  DEFINITION. 

D  DEVELOP  A  CONCEPT  OF  OPERATIONS  FOR  ACCOMPLISHING  PREEMPTIVE  ENGINEERING  FOCUSED 
AROUND  THE  AFLC  ISS/ISF  CONCEPT. 

E.  PROVIDE  SPECIFIC  LISTING  OF  ISS/ISF  STRENGTHS  AND  WEAKNESSES  IN  CONDUCTING  PR  'MPTlVE 
ENGINEERING  AND  A  ROADMAP  FOR  UPGRADING  THESE  ISS/ISF  TO  ACCOMPLISH  THE  TA^K.  COST 
ESTIMATES  SHOULD  BE  INCLUDED  IN  THIS  SUBTASK. 

3.  UPON  COMPLETION  OF  THE  STUDY,  THE  CONCEPT  OF  OPERATIONS  SHOULD  BE  CIRCULATED  WITHIN  THE 
AIR  FORCE  FOR  COORDINATION  AND  APPROVAL. 

4  CONCURRENT  WITH  ITEM  2.  AIR  STAFF  ACTION  SHOULD  BE  INITIATED  TO  DEVELOP  FUNDING  PROFILE 
AND  JUSTIFICATIONS 

8  ONCE  APPROVED.  THE  CONCEPT  OF  OPERATIONS  SHOULD  BE  IMPLEMENTED  IN  APPROPRIATE  AIR  FORCE 
REGULATIONS. 


LEVEL  OF  EFFORT 


AIR  FORCE:  WILL  REQUIRE  AFLC  AND  HQ  USAF/LEYY  SUPPORT  FOR  APPROXIMATELY  36  MONTHS  AFLC 
SUPPORT  WILL  RANGE  FROM  1  PERSON  FULL  TIME  TO  ONE  PERSON  HALF  TIME  OVER  THIS  PERIOD.  HQ 
USAF/LEYY  SHOULD  PI  AN  FOR  ONE  PERSON  TO  DEDICATE  V.  OF  THIS  TIME  TO  THIS  EFFORT  FOR  THE  36 
MONTHS. 


CONTRACTOR:  ECS  READINESS  FEASIBILITY  STUDY  TO  INCLUDE  THE  DEVELOPMENT  OF  AN  ECS  READINESS 
PREEMPTIVE  ENGINEERING  CONCEPT  OF  OPERATIONS  WILL  REQUIRE  A  MINIMUM  OF  48  PERSON  MONTHS 
SPREAD  OVER  AN  IB  MONTH  PERIOD. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


ENGINEER/SYSTEM  ANALYSIS  WITH  ,  'INIMUM  OF  TEN  1101  YEARS  EXPERIENCE.  STRONG  BACKGROUND  IN 
SYSTEM  requirements  ANALYSIS  ANu  system  design  IS  ESSENTIAL. 


TASK  INPUTS/INTERFACES 


1.  TASK  7  PROVIDES  ESSENTIAL  INFORMATION  FOR  THIS  EFFORT 

2.  THE  RESULTS  OF  THIS  EFFORT  WILL  IMPACT  THE  AUTOMATION  AND  STANDARDIZATION  OF  ECS  SUPPORT 
PROCESSES  MODULAR  EXTENDABLE  INTEGRATION  SUPPORT  FACILITIES.  AND  ECS  SUPPORT  NETWORKS 
INITIATIVES. 


TASK  DEUVERABLES/KEY  MILESTONES 

198? 

1983 

1984 

MONTH 

2 1 4l  el B  1 7o| 72 

(4 1  16  1  IB  |  70  |  22 1  24 

26 1  28 1  30 1  32 1  34 1  36 

t.  REQUEST  HQ  USAF/LEYY  SUPPORT 

(AFLCI 

A 

2.  REQUEST  WORKING  GROUP  SUP- 

PORT  IUSAF/LEYYI 

A 

3.  DEVELOP  SOW  1  AFLC) 

AA 

4.  LET  CONTRACT  (AFLCI 

A 

8.  ECS  READINESS  PREEMPTIVE 

A 

0.  CONCEPT  OF  OPERATIONS 

A 

A 

REVIEW/APPROVAL  (USAF/LEYY) 

44 

A* 

7.  DEVELOPMENT  OF  FUNDING 

PROFILE  AND  JUSTIFICATION 
(USAF/LEYYI 

A _ A 

8.  AF  IMPLEMENTATION  OF  CON- 

CEPTOF  OPERATIONS  (USAF/ 

A 

_ A 

SDR.  PDA,  CDR 

A 

A  A 

-- 

brt:  Preemptive  Engineering  Capability 
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ECS  READINESS 
CM  SYSTEM 
IDENTIFICATION 


SON/R&D 

REQUIREMENT] 


Figure  5-43.  ECS  Readiness  Support:  ECS  Readij 
System  Identification  I 
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ECS  READINESS  SUPPORT 


TASK  DESCRIPTION _ 

ECS  READINESS  CONFIGURATION  MANAGEMENT  (CMI 
SUBTASK  DESCRIPTION  SYSTEM  IDENTIFICATION _ 


© 


TASK  OBJECTIVES 
r~ 


TO  OBTAIN  AN  ECS  READINESS  CONFIGURATION  MANAGEMENT  SYSTEM. 


MAJOR  ISSUES/PROBLEM  AREAS 


1.  RESPONSE/MODIFICATION  TIME  (TASK  6)  IMPOSES  UNIQUE  CM  PROBLEMS. 

2.  ACTUAL  EXERCISES/TRAINING  UNDER  STRESS  CONDITIONS  IS  ESSENTIAL  TO  DOCUMENTING/ 
UNDERSTANDING  THE  CM  REQUIREMENTS  IN  THIS  AREA. 


TASK  APPROACH 


TASK  DEUVERABLES/KEY  MILESTONES  1*B2 


1984 


MONTH 


V  PLAN  AND  CONDUCT  EW  LOUD 
BYTE  EXERCiSE 

2  OOCUMENT  CM  REQUIREMENTS 

3.  PLAN  AND  CONDUCT  FIRE 
CONTROL  RADAR  EXERCISE 

4  DOCUMENT  CM  REQUIHEMENTS 

5.  DRAFT  CM  SYSTEM  SPFCIFICA- 
TIONS  STUDY  SOW  (AFLCI 

F  LET  CONTRACT (AFLCI 

7  CONDUCT  CM  SYSTEM  SPEC  FI 
CATIONS  STUOY 

8  SUBMIT  ITEM  7  RESULTS  FOR 
DEVELOPMENT /PROCUREMENT 
ACTIONS  IAFLC) 


(A 

A 


10  1  12  |  14 
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A 

A. 
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22  24  26  28 


:  ECS  Readiness  Configuration  Management  (CM) 
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analysis 

CAPABILITY 

ACQUISITION 


f  LIGHT  DATA  U$C 


THREAT 
SIMULATORS, 
RANGES  AND  AIR 
CREW  TRAINING 
DEVICES  UPDATE 


CONTRACT 

MONITOR 


RED  FORCE 
CENTER 


USER 

INTERFACE 


OTHER  SUBTASK 
INTERFACE 


Figure  5-44. 


ECS  Readiness  Support:  Threat  Si 
Devices  Update 


THREAT  SIMULATORS, 
RANGES,  A  NO  AIR 
CREW  TRAINING 
DEVICES  UPDATE 


OTHER  SUBTASK 
INTERFACE 


ECS  READINESS  SUPPORT 


TASK  DESCRIPTION _ 

THREAT  SIMULATORS.  RANGES,  AND  AIR  CREW 
SUBTASK  DESCRIPTION  TRAINING  DEVICES  UPDATE _ 


© 


TASK  OBJECTIVES) 


OBTAIN  THE  CAPABILITY  AND  RESOURCES  NECESSARY  TO  SUPPORT  AIRCRAFT  TRAINERS.  THREAT 
EMITTERS,  TRAINING  RANGE  SUPPORT  SYSTEMS.  AND  ACTIVE  C3  CM  SYf  TJMS. 


MAJOR  ISSUES/PROBLEM  AREAS 


RAPID  ECS  U^ChTES  IN  AIRCRAFT  SYSTEMS  MUST  BE  MATCHED  WITH  RESPONSIVE  CHANGES  IN  TRAINING 
ANO  EVALUATION  SYSTEMS.  RESPONSIVE  SUPPORT  OF  CJ  CM  DEVICES  IMPACTS  BOTH  TRAINING  AND 
OPERATIONAL  REQUIREMENTS. 


TASK  APPROACH 


V  DETERMINE  OPERATIONAL  USER  UPDATE  REQUIREMENTS. 

2.  CONSOLIDATE  USER  NEEDS.  DEVELOP  CONCEPT  OPERATIONAL.  AND  SUPPORT  SYSTEMS  SPECIFICATIONS. 

vo  include  requirements  for  intelligence  support. 

3.  DEVELOP  PLANNING  AND  IMPLEMENTATION  DOCUMENTS  AND  ACQUIRE  NECESSARY  SUPPORT  SYSTEMS. 

4.  MONITOR  INTELLIGENCE  DATA  FOR  IMPACTS  ON  TRAINING  AND  C3  COUNTER  MEASURE  SYSTEMS  AND 
WHERE  WARRANTED  INITIATES  PREEMPTIVE  ENGINEERING  PROJECTS. 

&.  ESTABLISH  BOTH  HARDWARE  AND  SOFTWARE  QUICK  REACTION  CAPABILITIES. 


LEVEL  OF  EFFORT 


THE  LEVEL  OF  EFFORT,  APPROXIMATELY  IS  PERSON  YEARS.  WILL  BE  DRIVEN  BY  OPERATIONAL  REQUIRE 
MENTS  AND  CHANGES  IN  INTELLIGENCE  BASELINES;  HOWEVER,  A  DEDICATE D  CORPS  OF  PEOPLE  SHOULD 
BE  IDENTIFIED  TO  MONITOR  THREAT  DATA  AND  INITIATE  ENGINEERING  P'  'JECTS. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


ENGINEERS.  ANALYSTS,  TECHNICIANS.  FAMILIAR  WITH  ELECTRONIC  WARFARE  SYSTEMS  PLUS  A  CORE  OF 
PEOPLE  KNOWLEDGEABLE  WITH  ENEMY  THREAT  SYSTEMS. 


TASK  INPUTS/iNTERFACES 

r 


INPUTS  FOR  USING  COMMANDS  AND  SUPPORT  FROM  INTE LLIGENCE  COMMUNITY  IS  ESSENTIAL. 


TriSK  DELIVERABLES/KEY  MILESTONES 


1982 


1983 


MONTH 


1.  OPERATIONAL  USER 
REQUIREMENTS 

2.  CONCEPT  OF  OPERATIONAL  AND 
SUPPORT  SYSTEM  SPECIFICATIONS 

3.  ACQUIRE  SUPPORT  SYSTEMS 

INTERIM 

AOVANCED 

4.  OPERATIONAL  ANO  MAINTENANCE 
OF  SYSTEM 

INTERIM 

ADVANCED 

5.  QUICK  REACTION  CAPABILITY 
IORCI 
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^  INPUT  FROM  RELATED  ACTIVITIES 


MANAGEMENT, 
ENGINEERING,  ACQUISITION, 
AND  SUPPORT  PRACTICES 


AUTOMATION  AND 
STANDARDIZATION  OF 
ECS  SUPPORT  PROCESSES 


•  MANAGEMENT,  DIRECTION 
.  •  PLANNING 

•  POLICY 

t  •  GUIDANCE 
I  •  BUDGET 
i  •  RESOURCES 

L- _ 


•  MANAGEMENT  TOOLS 

•  SUPPORT  TOOLS 

•  PROJECT  TOOLS 

•  PROCEDURES 

•  DATA  BASE 

•  INTERFACE 


MOOULAR  EXTENDABLE 
INTEGRATION 
SUPPORT  FACILITIES 


ECS  READINESS 
SUPPORT 


•  ARCHITECTURE 

•  SECURITY 

•  DATA  BASE 

•  SIMULATION 

•  COMMUNICATION 

•  LOCAL  NETWORK 


•  INTELLIGENCE 

•  SECURITY 

•  DATA  BASE 

•  PRIORITIES 

•  THREATS 

•  TRAINING 


REQUIREMENTS 

ANALYSES 

■ 

U  ~ _ 

SURVEY  OF 
CAPABILITIES 
ALL  MODES 

i  I 

1 _ 

I - 

SYSTEM/SEGMENT 

REQUIREMENTS 

DEFINITION 


CONCEPT  OF 
OPERATIONS 
STUDY 

■ 

EgQgl 

NETWORK 

NETWORK 

SEGMENT 

DEFINITION 

REQUIREMENTS 

DEFINITION 

j 

^  PRODUCTS 

•  TRADE-OFF  STUDIES 

•  ANALYSES  REPORTS  j 

•  SURVEY  REPORT 

•  CONCEPT  OF  OPERATIONS  STUDY 

•  NETWORK  AND  NETWORK  SEGMENTS  REQUIREMENTS 
DEFINITION  REPORT 

Figure  5-47.  ECS  Support  Networks:  j 
Requirements  Definition 
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TASK  DESCRIPTION  ECS  SUPPORT  NETWORKS _ 

COMMAND-WIDE  NETWORK  SYSTEM/SEGMENT 
SUBTASK  DESCRIPTION  REQUIREMENTS  DEFINITION _ 


TASK  OBJECTIVE(S) 


DEVELOP  INITIAL  ECS  SUPPORT  NETWORK  CONCEPT  AN*  UNCTIONAL  BASELINE  INCLUDING  NETWORK 
AND  NETWORK  SEGMENT  DEFINITIONS. 


J 


MAJOR  ISSUES/PROBLEM  AREAS 

THE  COMMAND-WIDE  ECS  SUPPORT  NETWORK  WILL  B3  DEVELOPED  CONCURRENTLY  WITH  EISF 
LOCAL  NETWORKS,  DATA  BASE  MANAGEMENT  SYSTFM  IMPLEMENTATION.  INTEGRATION  OF  WORK 
STATION  MODULES.  TRAINING  ANO  SOFTWARE  DEVELOPMENT  AND  SUPPORT  TOOLS.  EACH 
IMPACTING  TOTAL  NETWORK  DESIGN  REQUIREMENTS. 


TASK  APPROACH 


1.  ANALYSIS  CF  SUPPORT  FUNCTIONS  FOR  ATD.  ATE  C-E.  EW  AND  OFP  ON  PER-NODE  BASIS  INCLUDING 
DATA  PROCESSING.  DATA  BASE  MANAGEMENT  AND  COMMUNICATIONS. 

2  DEFINITION  AND  ANALYSIS  OF  INTERRELATIONSHIPS  BETWEEN  THE  ABOVE  SUPPORT  FUNCTIONS 
INCLUDING  SUPPORTING  DATA,  VOICE,  VIDEO  AND  FACSIMILE  COMMUNICATIONS  {FUNCTIONAL  FLOW>. 

3.  DEFlNITlO’i  OF  A  CONCEPT  OF  OPERATION  FOR  NETWORK  (INITIAL  SYSTEM  CONCEPT). 

4.  BASED  ON  SURVEYS  AND  TRADE  STUDIES  DEFINE  INTERCONNECT  STRUCTURE  AND  NETWORK  TOPOL¬ 
OGY  TO  HANDLE  ESTIMATED  COMMUNICATIONS  NEEDS  (I.E..  DATA  RATES.  RESPONSE  TIMES.  PHASED 
GROWTH,  LOCAL  NETWORK  TRAFFIC.  PRIVACY.  PRECEDENCE  HANDLING.  ETC.)  THE  LATTER  IS  BASED 
ON  ANALYTIC  AND  COMPUTERIZED  NETWORK  SIMULATIONS  OF  DOCUMENTATION  SYSTEM.  CONF1GURA 
TION  MANAGEMENT,  ELECTRICAL  MAIL,  ELECTRONICS.  AND  OTHER  TRAFFIC  REQUIREMENTS 

5  DEFINE  ECS  SUPPORT  NETWORK  INCLUDING  NETWORK  SEGMENTS  (I.E..  NETWORK  CONTROL  CENTER. 
EARTH  STATION.  EARTH  STATION  PORT  ADAPTER  SYSTEM,  SYSTEM  TEST  FACILITY,  HOST  INTERFACE 
DEVICES,  GATEWAY  DEVICES.  ETC  ). 

6.  DEFINE  IMPLEMENTATION  CONCEPT,  MAINTENANCE  AND  RECOVERY  PROCEDURES.  ARCHITECTURE, 
PROTOCOLS  AND  CONTROL  AND  MONITORING  PROCEDURES.  _ 


LEVEL  OF  EFFORT 

( - 

APPROXIMATELY  12  PERSON  YEAR  EFFORT  WITH  MOST  OF  LOADING  CONCENTRATED  ON  INITIAL  4  TO  5 
MONTHS.  ONE  SENIOR  SYSTEMS  ANALYST  ASSIGNED  TO  EACH  ECS  SUPPORT  CATEGORY  (I.E..  ATD,  ATE, 

C8.E,  EW  AND  OFP). 

b _ 

PE RFORM  .R  EXPERIENCE  LEVEL/BACKGROUND _ _ 

ENGINEERS/SYSTEM  ANALYSTS  WITH  A  MINIMUM  OF  SEVEN  (7)  YEARS  OF  EXPERIENCE  IN  LARGE  SCALE 
SYSTEMS  DESIGN  WITH  EMPHASIS  ON  NETWORKING  AND  COMMUNICATIONS,  A  FIRM  UNDERSTANDING  OF 
ADPE  AND  COMMUNICATIONS  FUNCTIONS  IN  ATD.  ATE,  C-E,  EW  AND  OFP  DEVELOPMENT  AND  TEST  IS 
HIGHLY  DESIRABLE. 


TASK  INPUTS/INTERFACES 

r  — “  -  ■  - - - ' 

KEY  INPUTS  ARE  REQUIRED  FROM  OTHER  SUBTASKS  SUCH  AS  DATA  BASE  MANAGEMENT  SYSTEM  TRAFFIC 
ANALYSIS. 


TASK  DELIVERABLES/KEY  MILESTONES 


1982 


bid 

a 

a 

-j 

CD 

U> 

10 

0 

12 

1.  TRADEOFF  STUDY,  TERRESTRIAL  AND  SATELLITE.  LONG- 
HAUL  NETWORK  ALTERNATIVES  (GOVT  &  COMM’L) 

2.  SURVEY,  EXISTING  AND  PLANNED  COMMUNICATIONS 
FACILITIES  AT  ALL  PERTINENT  NODES 

3.  NODE  COMMUNICATION  SUPPORT  FUNCTION  REQUIRE¬ 
MENTS  ANALYSIS  (ALL  NODES) 

4.  SUPPORT  FUNCTION  INTERRELATIONSHIP  DEFINITION 

5.  OPERATIONAL  SCENARIOS.  CONCEPT  OF  OPERATIONS, 

ECS  SUPPORT  NETWORK 

6.  DEFINITION  OF  INTERCONNECT  STRUC  TURE  AND  NET¬ 
WORK  TOPOLOGY 

7.  ECS  SUPPORT  NETWORK  DEFINITION 

8.  ECS  SUPPORT  NETWORK  SEGMENT  REQUIREMENTS 
DEFINITION 

9  SYSTEM  REQUIREMENTS  REVIEW  (SRR) 
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-A 


-A 
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bport  Networks:  Command -Wide  Network  System/ Segment 
fements  Definition 
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TRADE-OFFS 


t  PRODUCTS 

•  BUILD  OR  BUY  TRADE-OFF 

•  SPECIFICATIONS 

•  INTERFACE  CONTROL  DOCUMENTS  (ICD) 

•  SYSTEM  ENGINEERING  MANAGEMENT  PLAN 


Figure  5-48.  ECS  Support  Networks:  Commi 
Requirements  Validation 
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OFfiRAnCN  AND  : 
iUPPOAT 


TASK  DESCRIPTION  . 


ECS  SUPPORT  NETWORKS 


SUBTASK  DESCRIPTION. 
TASK  OBJECTIVES! 


COMMAND  WIDE  NETWORK  SYSTEM/SEGMENT 
REQUIREMENTS  VALIDATION _ 


e 


DEFINITIZED  SYSTEM/SEGMENT  DESIGN  FOR  ECS  SUPPORT  NETWORK  INCLUDING  SPECIFICATIONS  AT  BOTH 
SYSTEM  AND  SEGMENT  LEVEL  REQUIREMENTS  VALIDATION  OF  THE  VARIOUS  NETWORK  ELEMENTS  AND 
THEIR  INTEGRATION  INTO  AN  OPERATIONAL  SYSTEM 


MAJOR  ISSUES/PROBLEM  AREAS 


VALIDATION  MUST  BE  PERFORMED  CONCURRENTLY  FOR  ALL  FIVE  ECS  CATEGORIES/USER  COMMUNITIES 
ATD.  ATE.  C  E.  EW.  AND  OFP  OPERATIONAL  ASPECTS  MUST  BE  UNDERSTOOD  IN  ORDER  TO  VALIDATE 
QUANTITATIVE  NEEDS  II  E  .  NUM6EROF  VOICE  LINKS.  VIDEO  CHANNELS,  DATA  LINKS.  ETC  ) 


TASK  APPROACH 


A  BASELINE  ECS  SUPPORT  NITWORK  WILL  Bt  DEVE LOPED  WHICH  CAN  READILY  B'i  EXPANDEO  THE 
APPROACH  IS  BASED  ON  STARTING  SMALL,  MEET  THE  KNOWN  VALIDATED  REQUIREMENTS,  AND  GROW/  I 
EVOLVE  AS  REQUIREMENTS  AND  THE  NEEDS  FOR  SERVICE  INCREASE  THE  BASELINE  SYSTEM  WILL  THERE  ■ 
FORE  INITIALLY  $E  3VE  AS  AN  OPERATIONAL  TESTBEO  FOR  INTERFACING  OTHER  NETWORKS  AND  OE 
VICES  IT  WILL  BE  FiUlLT  IN  A  MODULAR  FASHION  USING  STANDARD  BUILDING  BLOCKS  SUCH  AS  EISF  NET 
WORK  INTERFACE  PROCESSORS,  STANDARDIZED  INTERFACES  AND  PROTOCOLS,  AND  STANDARD  SOFT 
WARE  LANGUAGE  TESTABLE  TO  THE  MODULE  LEVEL. 

SYSTEMS  SPECIFICATIONS.  SEGMENT  SPECIFICATIONS.  Cl  AND  CPCl  DEVELOPMENT  SPECIFICATIONS.  AND 
INTERFACE  CONTROL  REQUIREMENTS  DOCUMENTS  WILL  BE  DEVELOPED  WHiCH  DESCRIBE  THE  INITIAL 
BACKBONE  SYSTf.M  INCLUDING  GROWTH  OPTIONS.  SEGMENT  PERFORMANCE  ALLOCATIONS  WILL  BE  DE 
FINED  AND  A  DETERMINATION  WILL  BE  MADE  OF  USE  OF  OFF-THE-SHELF  S’*  STEMS  VERSUS  NEW 
DEVELOPMENTS 


LEVEL  OF  EFFORT 


APPROXIMATELY  16  PERSON  YEARS  OF  EFFORT  WITH  SEPARATE  TEAM  EFFORTS  FOR  REQUIREMENTS. 
SPECIFICATIONS.  AND  TRADEOFF  STUDIES 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


IN-DEPTH  EXPERIENCE  WITH  OPERATIONAL  NEEDS  AND  GROWTH  REQUIREMENTS  FROM  INFORMATION 
NEEDS  POIN'I  OF  VIEW  FOR  ATD.  ATE.  C-E.  EW  ANC  OFP 


TASK  INPUTS/INTERFACES 

DATA  BASE  MANAGEMENT  SYSTEM  DESIGN.  SOFTWARE  TOOLS  DEVELOPMENT  SYSTEM  SPECIFICATIONS 
WORK  STATION  INTERFACE  AND  REQUIREMENTS  SPECIFICATIONS.  DATA  BASE  MACHINE  SPECIFICATIONS. 
EISF  NETWORK  DESIGN  SPECIFICATIONS,  AND  FACILITY  SECURITY  REQUIREMENTS 


TASK  OELIVERABLES/KEY  MILESTONES 


1983 


MONTH 


1  SYSTEM  SPECIFICATION 

2  SEGMENT  SPECIFICATIONS 

3  Cl  DEVELOPMENT  SPECIFICATIONS 

A.  CPCl  DEVELOPMENT  SPECIFICATIONS 
5  EQUIPMENT  REQUIREMENTS 

f..  INTERFACE  CONTROL  REQUIREMENTS 
DOCUMENTATION 

7.  SYSTEM  ENGINEERING  MANAGEMENT  PLAN 

8  OFF-THE-SHELF  VERSUS  NEW  DEVELOP 
MENT  ASSESSMENT 

9.  SYSTEM  DESIGN  REVIEW  (SDR) 


2  1  3  1  4  1  ~5  1  6  7  T  Birr^T  l  -1  iT 
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Networks:  Command-Wide  Network  System/ Segment 
Its  Validation 
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FABRICATION/CODE 
AND  UNIT  T«T 


•  DESIGN  IMPLEMENTATION  PLAN 

•  RFP  PACKAGE 

•  VENDOR  SURVEY  REPORT 

•  DESIGN  DOCUMENTS 

•  FACILITIES 

•  EQUIPMENT 

•  SOFTWARE 

Figure  5-49.  ECS  Support  Networks:  Command-Wide 
Detailed  Design 


Iprpjt: 


TASK  DESCRIPTION  _ MS SMSEOfil NilttSb&S _ 

SUBTASK  DESCRIPTION  COMMAND  WIDE  NETWORK  PRELIMINARY  AND  DETAILED  DESIGN  £ 

TASK  OBJECTIVE!*) 

DETAILED  DESIGN  AND  DEVELOPMENT  OF  ALL  NETWORK  ELEMENTS  SUCH  AS  SATELLITE  ANO  GROUND 
LINKS.  INTERFACES  TO  LOCAL  NETWORKS  AND  NETWORK  CONTROL  FACILITY 


FABRICATION/COOE 
AND  UNIT  TEST  . 


MAJOR  ISSUES/PROBLEM  AREA* 

COORDINATION  WITH  OTHER  IMPLEMENTATION  ACTIVITIES  TO  AVOlO  DELAYS  DUE  TO  PROBLEMS  IN 
OTHER  AREAS  SUCH  AS  EtSF  NETWORK  DESIGN  AND  DATA  BASE  MACHINE  DEVELOPMENT 


TASK  APPROACH _ 

1.  ORGANIZATION  OF  NETWORK  DESIGN  AND  IMPLEMENTATION  SUPPORT  TEAM  FOR  PROPOSAL  EVALUA 
TION  AND  CONTRACTOR  MANAGEMENT. 

7  CONTRACTOR  CONTACTS  ANO  PREPROPOSAL  SUPPORT 

3.  PROPOSAL  EVALUATIONS.  VENDOR  SELECTIONS  AND  CONTRACT  AWARDS 

4.  DESIGN  AND  DEVELOPMENT  OF  EARTH  STATIONS.  CONTROLLERS  ANO  INTERFACE  DEVICES.  CABLES. 
CABLE  INTERFACE  UNITS.  MULTIPLEXERS.  MODEMS.  SWITCHES.  FRONT  END  PROCESSORS.  VIDEO  DIS 
TRIBUTION  SYSTEM.  VOICE  DISTRIBUTION  SYSTEM  AND  OTHER  NETWORK  ELEMENTS 

5.  DESIGN  «ND  DEVELOPMENT  OF  NETWORK  CONTROL  AND  MONITORING  SYSTEM 


LEVEL  OF  EFFORT 


APPROXIMATELY  16  PERSON  YEARS  WITH  MAJOR  EMPHASIS  ON  NETWORK  DESIGN  EXPERIENCE 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


SYSTEMS  ENGINEERS.  FACILITIES  ENGINEERS.  NETWORK  (COMMUNICATIONS)  ENGINEERS.  SOFTWARE 
DESIGNERS.  SYSTEMS  ANALYSTS.  MINIMUM  EXPERIENCE  7  10  YEARS  IN  RELATFO  SYSTEM  DESIGN 


TASK  INPUTS/INTERFACES 

/ - 

INTERFACE  WITH  OTHER  ON  GOING  PROGRAMMATIC  IMPLEMENTATION  ACTIVITIES.  IN  PARTICULAR  6 1SF 
LOCAL  NETWORKS  IT  IS  EXPECTED  THAT  THE  MAJORITY  OF  EQUIPMENT  CONSISTS  OF  OFF  THE  SHELF 
HARDWARE  AND  WITH  STANDARDIZATION  RULES  TO  BE  APPLIED  ACROSS  THE  BOARD  II  E  .  ElSF  NETWORK 
DEVELOPMENT! 

TASK  DELIVERABLES/KEY  MILESTONES 


1  DESIGN  IMPLEMENTATION  PLAN 
7  MANUFACTURE/VENDOR  SURVEYS 

3  ISSUE  RFP 

4  VENDOR/PROPOSAL  EVALUATIONS 

5  FACILITIES  DESIGN 
S.  EQUIPMENT  DESIGN 
7  SOFTWARE  DESIGN 
8.  PCR 

9  CDR 
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s:  Command -Wide  Network  Preliminary  and 


FACILITIES 
DEVELOPMENT 
AND  CONSTRUCT!" > 

“1  AUXILIARY 
I  EQUIPMENT 


MAJOR  CHANCE 
REQUIRED  DUE 
TO  TEST  RESULTS 


FABRICATION 

co-o-o-a 

DOC 

ooa 

r> 

UNIT 

TEST 

FABRICATION/CODE 
AND  UNIT  TEST 


SYSTEM 
INTEGRATION 
AND  TEST 


PROCUREMENT 
OF  OFF-THE- 
SHELF  HARDWARE 


UNIT  TEST 
•  HARDWARE 
•SOFTWARE 


CODING  OF 
NETWORK 

SOFTWARE 

UNIT 

TEST 

SOFTWARE 


PRODUCTS 


FACILITIES  TO  HOUSE  ALL  ECS  SUPPORT  NETWORK  ELEMENTS 

FABRICATED  BCARDS,  RACKS,  STANDS,  ENCLOSURES, 

CONSOLES  AND  OTHER  SUBSYSTEMS 

PROCURED  OFF-THE-SHELF  EQUIPMENT  (SATELLITES,  GROUND 
STATIONS  INCLUDING  ANTENNAE,  MODEMS,  MULTIPLEXORS,  ETC.; 

CODED  SOFTWARE  INCLUDING  LISTINGS 

TEST  REPORTS  ON  UNIT  TESTS  (HARDWARE,  SOFTWARE) 

AUXILIARY  EQUIPMENT  INCLUDING  CABLING*  ETC.) 


Figure  5-50.  ECS  Support  Networks;  Comma! 


TASK  DESCRIPTION  ECS  SUPPORT  NITWOHKS _ 

SUBTASK  nf  itrCIPTIftM  COMMAND  WIDE  network  f  abbiCate/code  and  unit  test 


i 

t 

l 

i 

\ 


SYSTEM 
INTEGRATION 
AND  TEST 


TASK  OBJECTIVES) 


f - — - \ 

PURCHASE  AND  FABRICATION  OF  ALL  ECS  SUPPORT  NETWORK  ELEMENTS  AND  CODING  OF  ALL  NETWORK/ 
COMMUNICATIONS  SQFTWARC 


J 


MAJOR  ISSUES/PROBLEM  AREAS 

IT  IS  PRESENTLY  DIFFICULT  TO  FORESEE  THE  MAGNITUDE  AND  TIME  SCALE  OF  THIS  TASK  AS  SOME  OR 
MOST  OF  THE  OFF-THE-SHELF  SUBSYSTEM  COMPONENTS  MAY  HAVE  TO  BE  MOOiFlED  OP  REDESIGNED  TO 
SATISFY  ECS  NETWORK  UNIQUE  REQUIREMENTS. 


TASK  APPROACH 

- - - 

1  DESIGN  AND  DEVELOPMENT  OF  ALL  NON  OF F  THE  SHELF  COMPONENTS  OF  THE  NETWORK 

2  PROCUREMENT  OF  ALL  OFF  THE  SHE LF  ELEMENT. 

3  DESIGN  AND  DEVELOPMENT  OF  ALL  UNIQUE  INTERFACES. 

4  CODING.  DEBUGGING  AND  CHECK  OUT  OF  ALL  NETWORK  PROCESSOR  SOFTWARE.  NETWORK  DIAG¬ 
NOSTIC  SOFTWARE  AND  NETWORK  STATISTICS  AND  DATA  COLLECTION  SOFTWARE 

5.  UNIT  TEST  OF  ALL  VIDEO.  VOICE  AND  FACSIMILE  SUBSYSTEMS 


LEVEIOF  EFFORT 

- - 

APPROXIMATELY  25  PERSON  YEARS  OF  EFFORT  WHICH  DOES  NOT  INCLUDE  ACTUAL  MANUFACTURING/ 
PRODUCTION  PERSONNEL. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

f - 

MANUFACTURING  AND  TEST  ENGINEERS  FAMILIAR  Wi  f H  COMMUNICATIONS  SYSTEMS  SUCH  AS  SATELLITE 
GROUND  STATIONS.  CONCENTRATORS  AND  INTERFACE  DEVICES.  PROGRAMMERS  AND  CODERS  WITH  A 
MINIMUM  OF  5  TQ  7  YEARS  OF  APPLICABLE  EXPERENCE 


TASK  iNPUTS/INTEnFACES _ 

DETAILED  INFORMATION  ON  INPUT/OUTPUT  CHARACTERISTICS/REQUIREMENTS  ON  ALL  NETWORK 
SUBSYSTEMS 


ELEMENTS 

E 5,  GROUND 
►LEX0R5,  ETC.) 


_ _ _ 

TASK  OE LIVER ABLES/KTY  MILESTONES  '**»  ’»<>« 

MONTH 

1  FABRICATION 

?  UNIT  TEST 

3.  PROCUREMENT  OF  OFF-THE-SHELF 

EQUIPMENT 

4.  UNIT  TEST  OF  OFF-THE  SHELF  EQUIPMENT 

5.  COOING  OF  NETWORK  SOFTWARE 

6  UNIT  TEST  OF  NETWORK  SOFTWARE 

'1 3 
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I  SYSTEM 
L  INTEGRATION 
AND  TEST 


OPERATION  AHO 
SUPPORT 


[PLANS 

fS  INCLUDING 
TEM 

f 

Per  faces 


TASK  DESCRIPTION  ECS  SUPPORT  NETWORKS _ _ _ 

SUBTASK  npgrniPTinN  command  wide  network  system  integration  and  test _ 

TASK  OBJECTIVES) 


INTEGRATION  AND  TEST  OF  Cl'S  AND  CPCI’S,  INTEGRATION  OF  ALL  HARDWARE/SOFTWARE  SUBSYSTEMS 
INTO  AN  OPERATING  NETWORK 


MAJOR  ISSUES/PROBLEM  AREAS 


TEST  AND  INTEGRATION  MUST  BE  PERFORMED  WITHOUT  INTERFERENCE  WITH  ON  GOING  OPERATIONS  AT 
THE  VARIOUS  NODES 


TASK  APPROACH 


1.  DEVELOPMENT  OF  Cl  AND  CPCl  TESTS  AND  TEST  PROCEDURES 
2  DEVELOPMENT  OF  SYSTEM  TEST  PROCEDURES  AND  TEST  TOOLS. 

3.  CI/CPCI  INTEGRATION  AND  TEST 

4  TOTAL  NETWORK  INTEGRATION  AND  TESTS  -  PERFORMEDON  INCREMENTAL  BASIS  Hi  .  VIDEO  ONLY. 
VOICE  ONLY.  DATA  ONLY.  TWO  NODE.  THREE-NODE.  NETWORK  SECURITY  LEVELS.  ETC. I- 


LEVELOF  EFFORT 


APPROXIMATELY  18  PERSON  YEARS  OF  EFFORT.  MAINLY  IN  DEVELOPING  TEST  PROCEDURES/EQUIPMENT 
AND  PERFORMING  HARDWARE  AND  SOFTWARE  INTEGRATION  AND  TEST.  THIS  WILL  REQUIRE  EXTENSIVE 
TRAVEL  DUE  TO  THE  NETWORK  GEOGRAPHIC  DISTRIBUTION 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


>  COMPUTfcR/SOFTWARE  INTEGRATION  AND  TEST  ENGINEERS.  FACILITIES  DESIGN  ENGINEERS.  SYSTEM 
INTEGRATION  ENGINE  E RS  WITH  A  MINIMUM  OF  TEN  YEARS  OF  EXPERIENCE 


TASK  INPUTS/INTERFACES 


AUTOPIN  II  TEST  SPECIFICATIONS.  EISF  LOCAL  NETWORK  TEST  PROCEDURES. 


TASK  DE LIVER ABLES/KEV  MILESTONES 

/• - - 

1  DEVELOP  CI/CPCI  TESTS/TEST  PROCEDURES 

2.  DEVELOP  TESTS/TEST  PROCEDURES  FOR  ECS 
SUPPORT  NETWORK 

3  PERFORM  CI/CPCI  INTEGRATION  AND  TEST 

4  PERFORM  NETWORK  INTEGRATION  AND  TEST 
b  FUNCTIONAL  CONFIGURATION  AUDIT  IFCA) 

6  PHYSICAL  CONFIGURATION  AUDIT  (PCAl 
7.  FORMAL  QUALIFICATION  REVIEW  IFQRI 
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DEVELOP 
MAINTENANCE 
AND  DOCUMEN¬ 
TATION  LIBRARY 


SYSTEM 

DOCUMENTATION 

UPDATE 


OPERATION  AND 
SUPPORT 


TRAINING 

COURSE 

DEVELOPMENT 


OPERATIONAL 
SUPPORT  AND 
NETWORK 
TESTING 


REMOTE 

_ 

NETWORK 

MONITORING 

vwfVlrU  1  fcK 

DIAGNOSTICS 

AND  DATA 
ANALYSIS 

EXPAND  ECS 

NETWORK 

CAPABILITIES 


PRODUCTS 


SYSTEMS  LIBRARY  WITH  DOCUMENTATION  ON  SYSTEM 

REMOTE  COMPUTER  DIAGNOSTICS  FACILITY 

TRAINING  COURSE  MATERIALS  AND  MANUALS, 

TRAINING  PLANS 

NETWORK  MONITORING  HARDWARE  AND  SOFTWARE 

OPERATIONAL  REPORTS  (INCLUDING  NETWORK  FAILURES, 
CONGESTION  (CHOKE)  POINTS,  UNUSED  CAPACITY,  ANOMALIES, 
ETC.,  BASED  ON  STATISTICS 

MAINTENANCE  REPORTS  (TYPES  OF  MAINTENANCE  PROBLEMS, 
LOGISTICS  SUPPORT  DEFICIENCIES,  ETC. ) 


Figure  5-52.  ECS  Support  Networks:  Command 
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TASK  DESCRIPTION  ECS  SUPPORT  NETWORKS _ _ _ _ 

SUBTASK  DPSrmPTION  COMMAND  WIDE  NETWORK  OPERATION  AN&JMPPOHT 
TASK  OBJECTIVE(S) 


TO  ASSURE  THAT  NETWORK  iS  FULLY  OPERATIONAL  AND  RESPONSIVE  TO  USER  NEEDS  WITH  MINIMAL 
DOWN  TIME  ALSO.  TO  KEEP  USER  ENVIRONMENT  AND  NETWORK  SUPPORT  PERSONNEL  ABREAST  OF  ALL 
AVAILABLE  NETWORK  RESOURCES  AND  NETWORK  TEST  AND  REPAIR  PROCEDURES,  RESPECTIVELY 

- - - 


MAJOR  ISSUES/PROBLEM  AREAS 


REMOTE  COMPUTER  DIAGNOSTIC  AND  NETWORK  MONITORING  SYSTEM  PROVISIONS  SHOULD  BE  '  BUILT  IN 
TO  THE  SYSTEM  DURING  DESIGN  PHASE  THIS  PHASE  IS  PARTLY  A  CONTINUATION  OF  THAT  WORK. 


V - - - J 

TASK  APPROACH 


\  MAINTENANCE  DOCUMENT ATION  LIBRARY  DEVE LOPMENT. 

2.  REMOTE  COMPUTER/NETWORK  DIAGNOSTIC  CAPABILITY  DEVELOPMENT. 

3  NETWORK  MONITORING  AND  STATISTICS  GATHERING. 

4  DEVELOPMENT  OF  TRAINING  COURSES  ANO  TRAINING  MATERIAL  FOR  NETWORK  USERS  AND  OPERA 
TIONS  PERSONNEL 

5  USING  CONFIGURATION  MANAGEMENT  SYSTEM.  UPDATE  SYSTEM  DOCUMENTATION  IN  TERMS  OF 
DEFICIENCY  CORRECTIONS  AND/OR  IMPROVEMENTS 

6  DEVELOPMENT  OF  OPERATIONAL  TEST  PROCEDURES  AND  TEST  EVALUATION  TOOLS. 


LEVEL  OF  EFFORT 


MAINTENANCE  DOCUMENTATION  EFFORTS  SPAN  A  FULL  YEAR.  TRAINING  COURSE  DEVELOPMENT 
EFFORT  REQUIRES  THREE  FIVE  ENGINEERS  OVER  ONE  YEAR.  NETWORK  MONITORING  IS  A  FOUR 
ENGINEER  V,  YEAR  EFFORT  TOTAL  LEVEL  OF  EFFORT  FOR  THIS  PHASE  IS  APPROXIMATE LY  13  PERSON 
YEARS 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


ALL  OF  THE  ABOVE  TASKS  RbUUlHt  PhhSONNEL  WITH  A  MINIMUM  OF  6  TO  6  YEARS  OF  RELATED 
EXPERIENCE 


TASK  INPUTS/INTERFACES 

r - - - - - - — - ■ — - s 

VENDOR  SUPPLIED  TRAINING  MATERIAL  {TO  BE  CONVERTED  TO  ECS  SUPPORT  NETWORK-UNIQUE  NEEDS). 
This  is  ALSO  TRUE  FOR  MAINTENANCE  DOCUMENTATION  DIAGNOSTIC  SUPPORT  DEVELOPMENT  CAPABIL  '■ 
ITY  IS  OBTAINED  IN  DESIGN  AND  DEVELOPMENT  ACTIVITY  PHASE  j 


TASK  DELIVERABLES/KEY  MILESTONES  1®B6  198? 


MONTH 


1.  MAINTENANCE  AND  DOCUMENTATION  LIBRARY 
2  REMOTE  COMPUTER  DIAGNOSTICS 
3.  NETWORK  MONITORING  AND  DATA  ANALYSIS 
4  TRAINING  COURSE  DEVELOPMENT 

5.  SYSTEM  DOCUMENTATION  UPDATE 

6.  NETWORK  OPERATIONAL  SUPPORT  INCLUDING 
OPERATIONAL  TESTING 
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A  MULTlPHASED  DEVELOPMENT  OF  ElS'/LOCAL  network  to  build  a  mature  and  robust  SUPPORT 
SYSTEM  BY  THE  END  OF  THE  19B0S  THE  FUCCS  WILL  BE  ON  RELIABILITY,  MAINTAINABILITY.  COST,  AND 
FLEXIBILITY  USING  PROVEN,  OFF-THE-SHELF  HARDWARE  AND  SOFTWARE,  WHEN  FEASIBLE.  TO  MINIMIZE 
DEVELOPMENT  RISK. 

MAJOR  ISSUES/PROBLEM  AREAS 

SUPPORT  OF  MULTIPLE  SYSTEMS  WITH  MULTIPLE  FUNCTIONS  (DIFFERENT),  COMPUTERS  WITH  DISSIMILAR 
ARCHITECTURES,  LANGUAGES,  PROGRAM  STRUCTURES.  AND  INPUT/OUTPUT  REQUIREMENTS  USING  COM¬ 
MON  HARDWARE  AND  SOFTWARE  MODULAR  BUILDING  BLOCKS. 


TASK  APPROACH 

THE  APPROACH  IS  BASED  ON  A  MULTl-PHASED  DEVELOPMENT  WITH  EXTENSIVE  TESTING  BETWEEN  THE 
PHASES.  TO  ASSURE  MAXIMUM  RELIABILITY,  MAINTAINABILITY,  AND  F  LEXIBILITY  FOR  MINIMUM  COST. 
INITIALLY.  A  BASELINE  SYSTEM  WILL  BE  DEVELOPED  AND  INSTALLED  IN  ONE  OR  TWO  FACILITIES,  TO 
ASSESS  CAPABILITIES  AND  LIMITATIONS  THIS  DESIGN  WILL  SUBSEQUENTLY  BE  REVISED  OR  UPGRADED 
BASED  ON  OPERATIONAL  EXPERIENCE  AND  REMAINING  FACILITIES  WILL  BE  INTERCONNECTED  INTER 
NALLY.  ALL  LOCAL  NETWORKS  WILL  THEN  BE  INTERCONNECTED  TO  FORM  A  COMMAND-WIDE 
NETWORK 


LEVEL  OF  EFFORT 

86  PERSON  YEARS  OF  EFFORT  (EXCLUDING  OVERALL  MANAGEMENT).  TOTAL  LEVEL  OF  EFFORT  ESTI¬ 
MATED  AT  APPROXIMATELY  100  PERSON  YEARS  ASSUMING  A  3-PERSON  MANAGEMENT  TEAM. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

SYSTEM  DESIGN,  INTEGRATION,  TEST.  AND  OPERATIONAL  SUPPORT  CAPABILITY  INVOLVING  ELECTRONIC, 
ELECTRICAL.  MECHANICAL.  AND  Ef'AviRONMENTAL  ENGINEERING  DISCIPLINES  WITH  EMPHASIS  ON  COM 
MUNICATIONS  TECHNOLOGY. 


TASK  INPUTS/INTERFACES 

DOD  NETWORK  STUDIES.  IEEE  STANDARDS,  EISF  REQUIREMENTS,  DOCUMENTS.  RELATED  STUDIES. 
AND  ECS  SUPPORT  NETWORK  DEVELOPMENT  TASK. 


TASK  DELIVERABLtS/KEY  MILESTONES 

BASELINE  SYSTEM 

1.  REQUIREMENTS  DEFINITION 

2.  REQUIREMENTS  VALIDATION 

3.  DESIGN,  FABRICATION,  AND  UNIT  TEST 

4.  CI/CPCI  INTEGRATION  AND  TEST.  NETWORK 
INTEGRATION  AND  TEST 

5.  OPERATION  AND  SUPPORT  ALL  7  NODES 

6.  REQUIREMENTS  REDEFINITION 
7  REQUIREMENTS  REVALUATION 

0.  DESIGN,  FABRICATION  AND  UNIT  TEST 

9.  CI/CPCI  INTEGRATION  AND  TEST;  NETWORK 
INTEGRATION  AND  TEST 

10.  OPERATION  AND  SUPPORT 


.  m  f 


rap 
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TASK  DESCRIPTION  60S  SUPPORT  NETWORKS _ 

EISF/LOCAL  NETWORK  SYSTEM/SEGMCNT  REQUIREMENTS 
SUBTASK  DESCRIPTION _ DEFINITION  (BASELINE  SYSTEM! _ 


TASK  OBJECTIVES) 

f  DEVELOP  INITIAL  EISF  NETWORK  CONCEPT  FOR  DATA,  VOICE.  AND  VIDEO  COMMUNICAT  ONS  SUPPORTING 
INFORMATION  EXCHANGE  BETWEEN  ATD,  ATE,  C-E,  £W.  AND  OFP,  IF  APPLICABLE  WITHIN  *  NODE 


MAJOR  ISSUES/PROBLEM  AREAS 


DEFINE  EISF  LOCAL  NETWORK  WHICH  111  IS  BASED  ON  ARCHITECTURE  INDEPENDENT  OF  TERMINAL  EQUIP 
MENT  AND  SYSTEMS.  IJI  IS  HIGHLY  RELIABLE  DUE  TO  DECENTRALIZED  CONTROL.  AND  131  CAN  BE 
EXPANDED  INTERNALLY  AND  COMMAND-WIDE  INTO  AN  ECS  SUPPORT  NETWORK  WITHOUT  ANY 
MODIFICATIONS  OR  HARDWARE  CHANGES 


TASK  APPROACH 

/“ -  -  "  -  —  .  - 

)  JOINT  NODE  COMMUNICATIONS  SUPPORT  FUNCT  ION  REQUIREMENTS  ANALYSIS  AND  DEFINITION 
PHASE-  ECS  SUPPORT  NETWORK  DEFINITION.  EMPHASIS  IS  ON  LOCAL,  RATHER  THAN  COMMAND¬ 
WIDE  INFORMATION  EXCHANGf. 

2.  TRADEOFF  STUDY  OF  OFF-THE  SHELF  LOCAL  NE  fWORKING  SYSTEMS  AN'J  THEIR  APPLICABILITY  TO 
EISF 

3  BASED  ON  REQUIREMENTS  ANALYSIS  AND  TRADEOFF  STUDY,  DEFINE  INTERCONNECT  STRUCTURE. 
THIS  WILL  TAKE  INTO  ACCOUNT  CONCEPT  OF  OPERATIONS  AND  QUANTITATIVE  REQUIREMENTS  OF 
NUMBER  OF  HANDSETS,  VOICE  CHANNELS,  VIDEO  CHANNELS.  NOMINAL  AND  PEAK  DATA  RATES,  NUM¬ 
BER  OF  INTERFACES.  ETC 

4  DEFINITION  OF  TWO  INITIAL  DEVELOPMENT  NODES,  INCLUDING  SEGMENT  REQUIREMENTS  (VOICE, 
VIDEO.  FAX  AND  DATA  SEGMENT). 


LEVEL  OF  EFFORT 

f  APPROXIMATELY  4  PERSON  YEAR  EFFORT 


PERFORMER  EXPERIENCE  f  VEUBACKGROUND 

rr  1  ”  ' 

ENGINEERS/SYSTEM  ANALYSTS  FAMILIAR  WITH  LOCAL  AREA  NETWORKS.  LOCAL  VIDEO  ANr  VOICE 
COMMUNICATION  TECHNOLOGY,  AND  OFP,  EW  AND  COMMUNICATION  AND  ELECTRONICS  DATA  EXCHANGE 
NEEDS  ASSESSMENT 


TASK  INPUTS/INTERFACES 


KEY  INPUTS  ARE  REQUIRED  FROM  OTHER  TRADEOFF  OR  STUDY  TEAM  EFFORTS  SUCH  AS  DATA  BASE 
MANAGEMENT  SYSTEM,  TRAFFIC  ANALYSIS,  AND  ECS  SUPPORT  NETWORK  REQUIREMENTS  DEFINITION 
SUBTASKS. 


TASK  DELIVERABLES/KEY  MILESTONES 


1982 


1.  TRADEOFF  STUDY.  LOCAL  AREA  NETWORK 
IMPLEMENTATION  ALTERNATIVES 


MONTH  111  21  3  I  4  I  5  I  6 


A 


2.  DETAILED  OPERATIONS  ANALYSIS,  COHOST,  TWO 
ORIGINALLY  NETTED  NODES 

3.  LINK  ALTERNATIVES,  LOCAL  NETWORK  TRAFFIC 
ANALYSIS,  COMMAND-WIDE  NET  EXPANSION. 
GATEWAY  ANALYSIS 

4.  EISF  NETWORK  DEFINITION 


A 


A 

-A1 


5.  P IS F  NETWORK  SEGMENT  REQUIREMENTS 
DEFINITION 

6.  SYSTEM  REQUIREMENTS  REVIEW 


9 


Figure  5-55.  ECS  Support  Networks:  EISF/ Local  Network 
System/ Segment  Requirements  Definition 
(Baseline  System) 
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TASK  DESCRIPTION. 


SUBTASK  DESCRIPTION. 


ECS  SUPPORT  NETWORKS _ 

EISF/LOCAl  NETWORK  SYSTEM/SEGMENT  REQUIREMENTS 
VALIDATION  (BASELINE  SYSTEM)  _ 


TASK  OBJECTIVE(S) 


SENIOR  NETWORK  DESIGN  ENGINEERS  FAMILIAR  WITH  DEVELOPING  REQUIREMENTS  DOCUMENTATION 
AND  VARIOUS  HARDWARE  AND  SOFTWARE  SPECIFICATIONS 


TASK  INPUTS/INTERFACES 


DETAILED  DOCUMENTATION  ON  ATD,  ATE.  C  E.  EW.  AND  OFP  SYSTEMS  INCLUDING  DATA  REQUIREMENTS, 
VOICE  AND  VIDEO  COMMUNICATIONS  NEEDS 


TASK  DESCRIPTION  . 


SUBTASK  DESCRIPTION. 


ECS  SUPPORT  NETWORKS  _ 

EISF/LOCAL  NETWORK  PRELIMINARY  AND  DETAILED  DESIGN 
(BASELINE  SYSTEM)  _ 


TASK  OBJECTIVES) 


Of  AILED  DESIGN  AND  DEVELOPMENT  OF  ALL  NETWORK  ELEMENTS  SUCH  AS  COMPUTER  AND  TERMINAL 
INTERFACES  VOICE  COMMUNICATIONS  INTERFACES.  VIDEO  AND  FACSIMILE  CHANNELS.  AND  INTER  AND 
INTRABUILDING  COMMUNICATIONS  LINKS 


MAJOR  ISSUES/PROBLEM  AREAS 


IN  ORDER  TO  MEET  THE  OVERALL  ECS  SUPPORT  NETWORK  SCHEDULE.  THIS  PHASE  MUST  BE  COMPRESSED 
TO  1«  MONTHS  IN  ORDER  TO  REDUCE  RISK  OF  SCHEDULE  OVERRUN,  THE  SYSTEM  MUST  BE  BASED  ON 
'  OFF  THE  SHELF  "  HARDWARE  AND  SOFTWARE  WITH  A  MINIMUM  OF  NEW  DESIGN 


Figure  5-57.  ECS  Support  Networks:  EISF/ Local  Network 

Preliminary  and  Detailed  Design  (Baseline  System 
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TASK  DESCRIPTION  ECS  SUPPORT NETWORKS _ 

E  IS F  /LOCAL  NETWORK  SYSTEM  INTEGRATION  AND  TEST 
SUBTASK  DESCRIPTION _ <gASELjNE  SYSTLMI _ 

TASK  OBJECTIVES) 


INT  F  ORATION  AND  TEST  OF  CIS  (OFF  THE  SHELF  AND  SPECIAL  DESIGN  INTERFACES!  AND  CPCl'S 
(OF  F  THE  SHI  i  r  SOI  TWARE  AND  UNIQUE  EISF  SOFTWARE!  INTEGRATION  Of  ALL  HARDWARE  AND 
SOFTWARE  f  LEMENTS  AT  EACH  NODE  INTO  A  LOCAL  STAND  ALONE  OPERATIONAL  ME  TWORK 


MAJOR  ISSUES/PROBLEM  AREAS 

IN  ORDER  TO  FIT  INTO  THE  ECS  SUPFORT  COMMAND  WIDE  NETWORK  SCHEDULE.  BOTH  BASELINE 
NODES  HAVE  TO  BE  INTEGRATED  AND  TESTED  CONCURRENTLY.  SINCE  BOTH  HAVE  SUGHTlY 
DM  FERENT  REQUIREMENTS.  THIS  WILL  PROVIDE  A  VERIF  ICATION  OF  THE  ■UNIVERSALITY'-  OF 
THE  DESIGN 

t.  ,,  —  _  -  -  -  -  -  --  -  ■  -  -« 

TASK  APPROACH 

~  - - \ 

\  DEVELOPMENT  OF  Cl  AND  CPCl  TEST  TOOLS  AND  TEST  PROCEDURES 

?  CI'CPCI  INTEGRATION  AND  TEST 

3  TOTAL  LOCAL  NETWORK  TESTING  INCLUDING  DIGITAL  DATA  TRANSMISSION  FILE  TRANSFER.  ACCESS 
FROM  TERMINALS  TO  FILES.  VIDFO  CONFERENCING.  VOICE  COMMUNICATIONS.  AND  LOCAL  FACSIMILE 
TRANSMISSION 


LEVEL  OF  EFFORT 

[  APPROXIMATELY  8  PERSON  YEARS  OF  EFFORT  EXPENDED  OVER  AN  EIGHT  MONTH  PERIOD 


i 


TASK  OEUVERABLES/KEY  MILESTONES  >»3  >964 


MONTH 

BB 

m 

IIBBIIB 

1  DEVELOP  TESTS/TEST  PROC- DURES  CMCPCI 

2 

2  DEVELOP  TESY  PROCEDURES  FOR  LOCAL  NETWORK 

3  DEVELOP  UNIQUE  TEST  EQUIPMENT 

pm 

_ A 

4  PERFORM  CI/CPC!  INTEGRATION  AND  TEST 

_ 

5  PERFORM  EISF  NETWORK  INTEGRATION  AND  TEST 

- A 

6  FUNCTIONAL  CONFIGURATION  AUDIT  (FCA1 

H 

A 

7  PHYSICAL  CONFIGURATION  AUDIT  (PCA) 

A 

8  FORMAL  QUALIFICATION  REVIEW  (FQR) 

&  I 

L 

- - - - 

J 

PERKORMER  EXPERIENCE  LEVEL/BACKGROUN0 

r~ - - — — — - - - - — - — - — - - - - — \ 

EXPERIENCED  ENGINEERS  AND  COMMUNICATION  SYSTEM  PROGRAMMERS.  FAMILIAR  WITH  SYSTEM  INTE 
C, RATION  AND  TEST  ON  SITE  ENGINEERS  FAMILIAR  WITH  TEST  EQUIPMENT  DESIGN 


TASK  INPUTS/INTERFACES 

f  DETAILED  INFORMATION  ON  ALL  INTERFACES  AND  SUBSYSTEM  FACILITIES 


Figure  5-58.  ECS  Support  Networks:  EISF/ Local  Network 
System  Integration  and  Test  (Baseline  System) 
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TASK  DESCRIPTION. 


ECS  SUPPORT  NF  -  K  ylRKS 


SUBTASK  npsrwiPrinN  eisf/local  networks  operation  and  support  (baseline  system) 

TASK  OBJECTIVE(S) 

TO  ASSURE  THAT  E »S^  BASELINE  NETWORK  IS  FULLY  OPERATIONAL  AND  RESPONSIVE  TO  USER  NEEDS. 
WITH  MINIMAL  IMPACT  ON  OPERATIONS  THE  SYSTEM  WILL  FUNCTION  IN  A  NORMAL.  DAY  TO  DAY  OPERA 
TIONAL  ENVIRONMENT  AND  WILL  ALSO  BE  USFD  TO  VALIDATE  THE  DESIGN  BEFORE  FULL  LOCAL  NET 
WORK  CAPABILITY  IS  DEVELOPED  IN  ALL  OF  THE  NODES 

MAJOR  ISSUES/PROBLEM  AREAS 

TO  OBTAIN  SUFFICIENT  INFORMATION  WITHIN  LESS  THAN  6  MONTHS  TO  ASSESS  DEFICIENCIES  OF  NET 
WORK  DESIGN.  IN  ORDER  TO  INFLUENCE  CHANGES  IN  UPGRADE 


TASK  APPROACH  _ 

1  DEVELOPMENT  of  LOCAL  ECS  SUPPORT  LIBRARIES. 

2  DEVELOPMENT  OF  EISF  NETWORK  DIAGNOSTIC  AND  MONITORING  CAPAf  ilI  i'Y. 

4  DEVELOPMENT  TRAINING  COURSES  AND  MATERIAL 

4  UPDATE  DOCUMENTATION  IN  TERMS  OF  DEFICIENCY  CORRECTIONS  AND/OR  IMPROVEMENTS 

5  DEVELOPMENT  OF  OPERATIONAL  TEST  PROCEDURES  AND  TEST  EVALUATION  TOOLS. 


LEVEL  OF  EFFORT _ 

C APPROXIMATELY  7  PERSON  YEAR  EFFORT  OVER  AN  8  MONTH  PERIOD 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND _ 

ENGINEERS  THOROUGHLY  FAMILIAR  WITH  DEBUGGING  COMPLEX  HARDWARE/SOFTWARE  SYSTEMS. 
TRAINING  EXPERTS  FAMILIAR  WITH  NETWORK  MAINTENANCE  AND  OPERATION. 


TASK  INPUTS/INTERFACES _ 

(input  OF  TEST  RESULTS  AND  OPERATIONAL  EXPERIENCES  INTO  ECS  SUPPORT  NETWORK  DESIGN  ACTlV 
IT Y.  INPUT  OF  INTERFACE  REQUIREMENTS  INTO  ABOVE  ACTIVITY 


TASK  DELIVERABLCS/KEY  MILESTONES 

r  -  — 

1.  MAINTENANCE  AND  DOCUMENTATION  LIBRARY 

2.  REMOTE  COMPUTER  DIAGNOSTICS 

3.  TRAINING  COURSE  DEVELOPMENT 

4  DOCUMENTATION  UPDATE 

5  OPERATIONAL  SUPPORT  WITH  INPUTS  TO  ECS 
DESIGN  ACTIVITY  ISM  AND  WRI 


MONTH  M|2|3|4|Sl6|7|8 


Figure  5-59.  ECS  Support  Networks:  EISF/ Local  Networks 
Operation  and  Support  (Baseline  System) 
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TASK  DESCRIPTION  ECS  SUPPORT  NETWORKS _ 

EISF/LOCAL  NETWORK  SYSTEM, SEGMENT  REQUIREMENTS 
SUBTASK  DESCRIPTION  REDEFINITION  (ALL  NODES) _ 

TASK  OBJECTIVES) 


[  BASED  ON  OPERATIONAL  EXPERIENCE  WITH  BASELINE  E ISP  NETWORKS.  THE  ORIGINAL  REQUIREMENTS 
DEFINITIONS  WILL  BE  UPGR ADE D  AND/OR  REDEFINED 


-J 


MAJOR  ISSUES/PROBLEM  AREAS 

- - - - — - - - 

THE  MAJOR  RISK  DUE  TO  SCHEDULE  SLIP  MAY  BE  THE  LACK  OF  'N$lGHT  INTO  OPERATIONAL  PROBLEMS. 
RESULTING  IN  XDDITION AL  NODES  BEING  DESIGNED  WITH  NO  IMPROVEMENTS.  THEREBY  POSTPONING  TKE 
IMPROVEMENT  CYCLE  WITH  RESULTING  MORE  EXPENSIVE  MODIFICATIONS. 

--  -----  —  -  ■  -  -  —  ______  _  -  -i 


TASK  APPROACH 

- X 

1.  REVISE  DEFINITION  OF  CONCEPTS  OF  OPERATION 

2.  EXPAND/REVISE  INTERCONNECT  STRUCTURE 

3.  DEFINE  REMAINING  DEVELOPMENT  NODES.  INCLUDING  SEGMENT  REQUIREMENTS. 


L  EVEL  OF  EFFORT _ 

(APPROXIMATELY  6-5  PERSON  -  EARS  OF  EFFORT  OVER  A  «  MONT  H  PERIOD  WITH  TWO  OPERATION  ANAL 
YST  ASSIGNED  TO  EACH  FACILITY. 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

r  ~  - - - — * — - 

ENGINEERS  AND  SYSTEMS  ANALYSTS  FAMILIAR  WJTH  LOCAL  AREA  NETWORKING.  VIDEO  CONFERENCING. 
VOICE  COMMUNICATIONS.  AND  ELECTRONIC  MAIL.  PERSONNEL  SHOULD  BE  FAM'llAR  WITH  PREVIOUS 
EFFORTS  IN  THIS  TASK  II. E..  BASELINE  SYSTEM!. 


TASK  INPUTS/INTERFACES 

r - - 

INTERFACES  WITH  ECS  SUPPORT  COMMAND-WIDE  NETWORK  DESIGN  TFAM. 

- - J 


TASK  DELIVERABLES/KEY  MILESTONE  ,984  ^5 


/“  "  "  -  -  - ^ — — — — — — — 

— 1 - 

r  ~ 1 

—  \ 

MONTH 

i  1  j 

3  i  4 

1  EXPANDED  OPERATIONS  ANALYSIS  FOR  ALL  NODES 

2.  TRAFFIC  ANALYSIS  UPGRADE.  INCLUDING  EXPANDED 

TRAFFIC  REQUIREMENTS 

3.  EISF  NETWORK  DEFINITION  REVISION 

rz* _ l 

4  REVISED  EISF  NETWORK  SEGMENT  REQUIREMENTS 

A 

S.  SYSTEM  REQUIREMENTS  REVIEW 

_ -/ 

Figure  5-60.  ECS  Support  Networks:  EISF/ Local  Network 
System/ Segment  Requirements  Redefinition 
(All  Nodes) 
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r 


j  I 


E 


trs  support  networks 


TASK  DESCRIPTION _ 

£l$F/LOCAl  NETWORK  SYSTEM 'SEGMENT  REQUIREMENTS 
SUBTASK  DESCRIPTION  _  fcFVAUQA  t  IQN.  jAU  NODES) _ 


TASK  OBJECTIVE(S) 


RE  DE  FlNlT  lZED  LOCAL  AREA  NETWORK  (EISFj  DESIGN  INCLUDING  CHANGES/ADDlTlONS/OE  LET  IONS  TO 
f  XISTING  DESIGNS  BASEDON  OPERATIONAL  EXPERIENCES  WITH  THE  BASELINE  SYSTFMIS) 


MAJOR  ISSUES/PROBLEM  AREAS 


THE  VALIDATION  SHOULD  ALSO  ENCOMPASS  EXISTING  BASELINE  FACILITIES  DESIGN  UPGRADES  IlF  ANY! 
INCLUDING  VALIDATED  REQUIREMENTS  FROM  ECS  SUPPORT  NETWORK  VALIDATION  AND  DESIGN  TASKS 


TASK  APPROACH 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 


SENIOR  NETWORK  DESIGN  ENGINEERS  FAMILIAR  WITH  DEVELOPING  REQUIREMENT  DOCUMENTATION  AND 
VARIOUS  HARDWARE  AND  SOFTWARE  SPECIFICATIONS 


TASK  INPUTS/INTERFACES 


TASK  INPUTS  FROM  ElS  1  A$EL»NE  VAL.DATION  PHASE  AND  OPERATIONS  AND  SUPPORT  PHASE.  KEY 
INPUTS  ARE  ALSO  REQUIRED  FROM  ECS  SUPPORT  COMMAND-WIDE  NETWORK  VALIDATION  AND 
DESIGN  TASKS 


TASK  DELIVERABLE  S/KEY  MILESTONES 


MONTH 


V  S  .  STEM  SPECIFICATION  REVISION 
2.  SEGMENT  SPECIF  ICATtON  REVISION 

3  Cl  DEVELOPMENT  SPECIF  ICATION  REVISIONS 

4  CPCl  DEVELOPMENT  SPECIFICATION  REVISIONS 

5  ECUIPMENT  REQUIREMENTS  UPGRADE 
6.  FACILITIES  MODIFICATION  PLANS 

7  UPDATED  ICD'S 

8.  UPDATED  SYSTEM  ENGINEERING  MANAGEMENT  PLAN 
9  BUiLD  OR  BUY  ASSESSMENT 
10  SDF> 


-A 


A 


A 


i  i 

i 


Figure  5-61. 


ECS  Support  Networks:  EISF/ Local  Network 
System/ Segment  Requirements  Revalidation 
(All  Nodes! 
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TASK  DESCRIPTION _ ECS  SUPPORT  NETWORKS 


SUBTASK  DESCRIPTION. 


E  ISF  /LOCAL  NETWORK  F  ABDICATION /CODE  AND  UNIT 
TEST  IALL  NODES!  _  _ 


TASK  OBJECTIVES) 

or  tailed  design  and  development  of  all  network  elements  for  all  nun-netted  eisf  nodes 

AS  WELL  AS  POSSIBLE  CHANGES'UPGRAOES  TO  THE  UASELINE  SYSTEM 


MAJOR  ISSUES/PROBLEM  AREAS 

f  TO  MAINTAIN  f ULL  COMPATIBILITY  BETWEEN  ALL  NODES  AND  TO  M'NlMlZE  CHANGES  TO  EXISTING  BASE 
LINE  NODES  IN  ORDE  R  NOT  TO  DISRUPT  DAY  TO-DAY  OPERATIONS 


TASK  APPROACH 


TASK  INPUTS/INTERFACES 

FACILITIES  REQUIREMENTS.  SECURITY  REQUIREMENTS.  ECS  SUPPORT  NETWORK  REQUIREMENTS. 


TASK  DE  LIVER  ABLE  S/KEV  MILESTONES _ 

1.  DESIGN  IMPLEMENTATION  PLAN 
.  REVISE  AND  ISSUE  RFP 
:  UNIQUE.  NEW  INTERFACE  OESIGNS 

4.  r  DR  AND  CDR 

5.  FACILITIES  DESIGN 

6  E IS F  NETWORK  SOFTWARE  ADDITIONS  DESIGN 

7  FABRICATION  OF  HARDWARE 

8.  HARDWARE  UNIT  TEST 

9.  SOFTWARE  CODE  AND  TEST 

10  OFF  THE  SHELF  EQUIPMENT  ACQUISITION  AND 
TEST 


Figure  5-62.  ECS  Support  Networks:  EISF/ Local  Netv/ork 
Fabrication/Code  and  Unit  Test  (All  Nodes) 
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TASK  DESCRIPTION 


fees  SUPPORT  NETWOHKS 


SUBTASK  description  e isp/local  network  system  integration  and  test  (all  nodes) 

TASK  UBJECTIVE(S) 

f - ■ - - - ■“ 

INTEGRATION  AND  TEST  of  CIS  ANDCPCI'SIALI  NEW  HARDWARE  AND  SOFTWARE  ELEMENTS  OR 
SUBSYSTEMS  WHICH  HAVE  BEEN  REDESIGNED  OR  UPGRADED)  NTEGRATION  AND  TEST  OF  ALL 
HARDWARE  AND  SOFTWARE  AT  REMAINING  NOOES 

MAJOR  ISSUES/PROBLEM  AREAS 

THE  LOCAL  NETWORK  INTEGRATION  AND  TEST  WILL  BE  FOLLOWED  BY  THE  ECS  SUPPORT  NETWORK 
INTEGRATION  AND  TEST  FOR  COMMANDWIDE  NETWORK  CHECKOUT  WORK  MUST  BE  PERFORMED 
CONCURRENTLY  AT  AIL  NODES  REQUIRING  OVERLAPPING  RATHER  THAN  STAGGERED  EFFORTS 


TASK  APPROACH 

\.  REVISION  OF  ALL  DOCUMENTS  AND  EQUIPMENT  PERTAINING  TO  INTEGRATION  AND  TESTING  OF 
BASELINE  CONFIGURATION 

2  Cl'CPCI  INTEGRATION  AND  TEST  WITH  EMPHASIS  ON  CHECKOUT  OF  UPGRADED  CAPABl LITiES 

3  TOTAL  LOCAL  NETWORK  TESTING  AT  ALL  SITES. 


LEVHL  OF  EFFORT 

(^APPROXIMATELY  9  PERSON  YEARS  OVER  A  7  MONTH  PERIOD 


PERFORMER  EXPERIENCE  LEVEL/BACKGROUND _ 

ENGINEERS  EXPERIENCED  IN  TEST  EQUIPMENT  DESIGN.  TEST  PROCEDURES.  HARDWARE/SOFTWARE 
INTEGRATION  AND  TEST  AND  SYSTEM  INSTALLATION  AND  TEST.  ON  SITE. 


TASK  INPUTS/INTERFACES 

(INTEGRATION  WITH  ECS  NETWORK  INTEGRATION  AND  TEST  ACTIVITY. 


TASK  DELIVERABLES/KEY  MILESTONES 


V  REVISE  TEST  PROCEDURES.  CUCPCI 

2.  REVISE  TEST  PROCEDURES  FOR  LOCAL  NETWORK 
FUNCTIONS 

3.  MODIFY  UNIQUE  TEST  EQUIPMENT 

4.  PERFORM  CI/CPCI  INTEGRATION  AND  TEST 

5  PERFORM  EISF  NETWORK  INTEGRATION  AND  TEST 
FOR  EACH  NODE 

6.  FUNCTIONAL  CONFIGURATION  AUDIT  (FCA) 

7.  PHYSICAL  CONFIGURATION  AUDIT  tPCA) 

8.  FORMAL  QUALIFICATION  REVIEW  (FOR) 


Figure  5-63.  ECS  Support  Networks:  EISF/ Local  Network 
System  Integration  and  Test  (All  Nodes) 
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TASK  DESCRIPTION 


ECS  SUPPORT  NETWORKS 


SUBTASK  DESCRIPTION. 
TASK  OBJECTIVES) 


DATA  BASE  MACHINE  SUMMARY  T ASK  SHEET 


© 


TO  PROVIDE  EASY  AND  FAST  ACCESS  TO  A  WIDE  VARIETY  OF  DATA  ASSOCIATED  WITH  ATD,  ATE. 
C  E,  EW,  AND  OFP  WHILE  ENSURING  THAT  THIS  DATA  1$  CURRENT. 


MAJOR  ISSUES/PROBLEM  AREAS 


IT  IS  POSSIBLE  THAT  NO  ONE  TYPE  »F  DATA  BASE  MACHINE  CAN  SATISFY  THE  DIVERSE  REQUIREMENTS  OF 
AFLC  THEREBY  NECESSITATING  THE  COMB. NATION  ©F  DISTRIBUTED  DATA  BASES  TOGETHER  WITH  DATA 
BASE  MACHINES  AT  ALL  LOCAL  NODES. 

TASK  APPROACH 


SURVEY  DATABASE  NEEDS  AT  ALL  ECS  SUPPORT  F  ACILIT IES  USING  FORMAL  SURVEY  FORMS  AS  WELL 
AS  USER  INTERVIEWS. 

DEVELOP  SPECIFICATIONS  FOR  THE  DATA  BASE  MACHINE. 

DESIGN.  FABRICATE  AND  TEST  THE  DATA  BASE  MACHINE  (THIS  COULD  BE  AN  OFF-THE-SHELF  SYSTEM 
OR  A  MINICOMPUTER-BASED  SYSTEM  WITH  A  STANCARD  DATA  BASE  MANAGEMENT  SYSTEM.) 

INTEGRATE  THE  DATA  BASE  MACHINE  INTO  EACH  EISF  NETWORK. 

CHECK  OUT  REMOTE  ACCESS  <N  OPERATIONAL  ENVIRONMENT  USING  ECS  SUPPORT  NETWORK. 


LEVEL  OF  EFFORT _ 

"WoTAL  OfTs^ERSOnVeARS  OVER  A  5  YEArTerToD.  LEVEL  OF  EFFORT  !S  EXPANDED  WHEN  DATA 
BASE  MACHINES  ARE  INSTALLED  IN  ALL  EISF  NETWOHK  NODES  IN  198G. 


v - - - - - 

PERFORMER  EXPERIENCE  LEVEL/BACKGROUND 

s - - - 

BROAD  EXPERIENCE  IN  DATA  BASE  MANAGEMENT  SYSTEM  DESIGN  INCLUDING  DISTRIBUTION  OF  DATA 
BASES  AND  REMOTE  ACCESS 


TASK  INPUTS/INTERFACES _ _ 

INPUTS  FROM  THE  EISF  LOCAL  NETWORK  DESIGN  TASK  AND  ECS  SUPPORT  COMMAND-WIDE 
NETWORK  DESIGN  TASK.  A  KEY  INPUT  IS  FROM  THE  SECURITY  REQUIREMENTS  IN  ECS  SUPPORT 
NETWORK  REQUIREMENTS  DEFINITION  PHASE. 

-  4 

TASK  PELtVERABLES/KEY  MILESTONES _  } 


** . 

1982  |  1983  |  1984  |  198b  |  1986 

.  A 

2.  DATA  BASE  MANAGEMENT  SPECIFICATION  (SDR) 

3.  INTERFACE  CONTROL  DOCUMENTS 

_ & 

4.  DESIGN  AND  FABRICATION  PROCUREMENT 

A_A 

PDR,  CDR) 

5.  INTEGRATION  AND  TEST 

—A 

6  OPERATION  AND  SUPPORT 

- L 

- - - 

Figure  5-65.  ECS  Support  Networks:  Data  Base  Machine 
Summary  Task  Sheet 
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APPENDIX  A 


EMBEDDED  COMPUTER  SYSTEM 
SUPPORT  OBJECTIVES 

The  following  embedded  computer  system  (ECS)  support  objectives  were  distilled  from  a 
longer  list  of  specific  problem  or  definiency  related  objectives.  They  encompass  known  and  pro¬ 
jected  ECS  support  requirements.  They  are  an  extension  of  the  current  Statement  of  Need/Mis¬ 
sion  Element  Need  Analysis  and  serve  as  statements  of  Air  Force  Logistic  Commands  intentions 
for  support  of  the  five  category  of  ECS,  The  initiatives  presented  in  the  long  range  ECS  support 
plan  are  intended  to  achieve  these  objectives. 

A.  1  ACQUIRE  AND  MAINTAIN  A  FLEXIBLE  TECHNICAL  SUPPORT  BASE  AND 
ESTABLISH  DATA  FLOW  TO  RAPIDLY  RESPOND  TO  ECS  COMBAT  NEEDS 

Enhanced  performance  and  flexibility  of  weapon  systems  is  being  achieved  by  incor¬ 
porating  integral  embedded  computer  systems.  These  capabilities,  however,  can  only  be  realized 
or  sustained  by  acquiring  and  maintaining  an  equally  flexible  technical  support  base  and 
associated  data  flow.  The  technical  support  base  provides  the  capability  to  stay  ready  for  the 
known  operational  environment  as  well  as  the  capability  to  react  quickly  to  combat  require¬ 
ments.  Readiness  prior  to  hostilities  involves  the  exploitation  of  technology  and  intelligence.  In 
this  context,  ECS  support  needs  are  closely  coupled  to  weapon  system  readiness. 

The  ECS  change  process  is  a  continuing  activity  that  begins  early  in  the  ECS  life  cycle  but 
commences  officially  for  AFLC  at  PMRT.  It  encompasses  all  ECS  categories  and  frequently 
includes  multiple  versions  of  operational  software  for  a  single  ECS.  The  ECS  change  process  is 
engineering  intensive,  requires  close  interaction  with  the  user,  and  is  performed  primarily  in  a 
laboratory  environment.  It  involves  software  error  correction,  ECS  enhancement,  and  the  addi¬ 
tion  of  new  capabilities.  The  responsiveness  of  ECS  change  support  is  a  function  of  the  system 
design  and  complexity  and  the  tools  and  expertise  committed  to  it.  The  capability  for  ECS 
change  support  is  fundamental  to  ECS  readiness. 

A. 2  PROVIDE  EFFICIENT  AND  EFFECTIVE  LIFE  CYCLE  ECS  MANAGEMENT  AND 
SYSTEM  ENGINEERING  SUPPORT 

The  technical  management  and  system  engineering  functions  are  closely  related  because 
ECS  and  support  system  acquisition  and  operation  are  predominantly  engineering  and  scien¬ 
tifically  oriented  activities  throughout  the  life  cycle.  While  the  technical  management  function 
typically  relies  primarily  on  management  oriented  plans  and  controls,  it  encompasses  the  system 
engineering  function  particularly  in  the  initial  or  early  stages  of  the  ECS  life  cycle.  The  system 


A'l 


engineering  function,  which  varies  in  magnitude  with  ECS  complexity,  primarily  supports  the 
management  function  and  is  dependent  upon  tools  like  those  in  a  typical  ECS  support  facility. 
The  system  engineering  function  is  significant  for  continuous  ECS  change  support  as  well  as  for 
ECS  support  system  acquisition  and  major  ECS  and  associated  support  system  modification 
and  retrofit  programs. 

A. 3  PROMOTE  EFFICIENT,  EFFECTIVE,  AND  TIMELY  USE  OF  INTERSERVICE  AS 
WELL  AS  INTER  AND  INTRA  COMMAND  ECS  SUPPORT  RESOURCES 

Several  Department  of  Defense  initiatives  have  been  aimed  at  unifying  the  various  services 
approach  to  the  support  of  embedded  computer  systems.  While  these  initiatives  primarily 
address  standardization  on  a  broad  range  of  topics,  the  advent  of  joint  service  weapon  system 
programs  raises  the  potential  for  complex  interservice  ECS  support  arrangements.  When  viewed 
in  a  “western  world”  context  the  sharing  of  available  DOD  ECS  support  resources  looms  as  an 
important,  if  not  overriding,  factor  in  the  future  support  of  multiservice  ECS  acquisitions.  In 
addition,  interoperability  of  the  ECS  in  service  and  DOD  weapon  system  should  benefit  from 
standardization  of  instruction  set  architecture,  languages,  and  interfaces  along  with  modular 
design  of  ECS  and  ECS  support  systems. 

A. 4  ACQUIRE  AND  MAINTAIN  QUALITY  ECS  AND  ECS  SUPPORT  SYSTEMS 

The  Quality  and  supportability  of  ECS  and  associated  support  systems  have  a  direct  rela¬ 
tionship  to  the  AFSC/AFLC/USER  management  attent  on,  and  the  engineering  discipline 
imposed  during  the  planning  and  acquisition  process.  Quality  and  supportability  considerations 
start  with  clearly  stated  requirements  by  AFLC/USER  and  coordination  with  AFSC  for  the  ini¬ 
tial  ECS  and  support  system  design.  Product  quality  assurance  at  or  prior  to  PMRT  will  be 
enhanced  by  application  of  independent  verification  and  validation  techniques.  ECS  and  sup¬ 
port  systems  quality  after  PMRT  is  dependent  upon  adequate  documentation  which  must  be 
acquired  with  the  product  and  rigorously  controlled  through  automated  processes  to  maintain 
product  baselines. 

A. 5  ENSURE  CURRENCY  AND  SURVIVABILITY  OF  ECS  SUPPORT  SYSTEMS 

The  currency  of  ECS  support  systems  is  an  ongoing  activity  that  affects  each  category,  and 
encompasses  all  related  or  associated  support  systems  for  any  given  weapon  system.  Changes  to 
the  operational  ECS  or  the  weapon  system  initiates  a  rippling  affect  throughout  the  various  ECS 
support  systems.  While  currency  of  ECS  support  systems  is  directly  related  to  ECS  mission 
readiness  on  a  day  to  day  basis,  survivability  is  a  concern  in  the  event  of  hostilities  or  natrual 
disaster.  Mission  essential  ECS  and  support  systems  should  be  identified  and  prioritized,  and 
documentation  in  the  form  of  geographically  separated  libraries  and  repositories  must  be 


established  and  maintained  to  enable  reconstitution  of  emergency  ECS  support  capability.  In 
addition,  fielded  or  flight  line  extensions  of  ECS  support  facilities  should  be  designed  to  include 
redundancy  for  key  elements  as  a  backup  capability. 

A. 6  ACQUIRE  AND  MAINTAIN  ECS  TECHNOLOGY  AND  INTELLIGENCE  BASES 
AND  PROVIDE  FOR  INTERCOMMAND  AND  INTERSERVICE  EXCHANGE  AND  USE 
OF  DATA 

Embedded  computer  systems  and  corresponding  support  systems  are  an  outgrowth  of 
technology  and  operational  requirements  for  a  flexible  response  to  changes  in  enemy  weapon 
systems  and  tactics.  The  use  of  embedded  computers  and  software  permits  the  developmentof 
highly  flexible  weapon  systems.  ECS  technology  is  progressing  at  such  a  rapid  rate,  when  com¬ 
pared  to  weapon  system  development,  that  the  potential  exists  for  the  use  of  more  advanced 
technology  in  ECS  suport  systems  than  is  incorporated  in  the  ECS  itself.  This  is  possible, 
however,  only  if  the  ECS  support  community  is  in  the  technology  loop,  and  is  postured  to 
exchange  the  knowledge  and  apply  it  to  ECS  support  needs.  Intelligence  data,  on  the  other 
hand,  is  necessary  to  ensure  ECS  quick  reaction  as  well  as  for  preemptive  engineering  in  an  en¬ 
vironment  characterized  by  the  continuous  “move-countermove”  techniques  employed  by 
adversaries.  This  interaction  is  dependent  upon  not  only  access  to  intelligence  data  but  the  abili¬ 
ty  to  influence  the  collection,  analysis  and  dissemination  of  the  data  through  clearly  stated  requ¬ 
irements.  The  exchange  and  use  of  ECS  technology  and  intelligence  data  enhances  completeness 
and  reduces  duplication. 

A. 7  ENSURE  AN  ATTRACTIVE  AND  COMPETITIVE  ECS  MANAGEMENT  AND 
ENGINEERING  CAREER  FIELD 

ECS  managers  and  engineers  need  improved  career  management  programs.  These  pro¬ 
grams  should  include  qualification  and  classification  standards  along  with  new  terms  and  series 
for  job  descriptions  and  professional  degrees  for  all  ECS  support  skill  needs.  Special  experience 
identifiers  (SEI’s)  should  be  established  and  used  for  tracking  and  assigning  both  military  and 
civil  service  ECS  personnel.  The  objective  is  to  assign  personnel  to  a  challenging  job  within  their 
area  of  professional  education,  training  and  interest,  and  provide  growth  to  new  challenges  and 
responsibilities  through  demonstrated  performance.  Management  should  ensure  equity  in  the 
system  by  using  the  standards,  SEI’s  and  personnel  evaluations  for  assigning,  tracking,  and  pro¬ 
moting  ECS  support  personnel. 

A. 8  MINIMIZE  CRITICAL  ORGANIC  ECS  ENGINEERING,  SCIENTIFIC  AND 
TECHNICAL  SKILL  NEEDS 

While  the  total  number  of  ECS  engineering,  scientific  and  technical  personnel  needed  is 
almost  certain  to  increase  in  the  next  decade,  this  objective  addresses  the  long  held  logistics 
maintenance  support  policy  of  striving  to  use  lower  skilled  personnel  for  long  term  or  extended 


support  tasks.  Although  ECS  support  is  an  engineering  intensive  activity,  certain  aspects  of  the 
ECS  support  process,  if  properly  structured  and  automated,  can  be  definitized  and  procedurally 
implemented  to  change  the  current  skill  mix.  Another  facet  of  this  objective  is  to  reduce  the 
numbers  of  highly  skilled  engineers  and  scientists  by  centralizing  or  collecting  critical  organic 
personnel  resources,  with  augmentation  from  industry  sources  for  complementary  skills,  to 
satisfy  multiple  source  needs. 

A. 9  PROVIDE  FOR  EFFICIENT  AND  EFFECTIVE  TRAINING  AND  CROSS-TRAINING 
IN  ECS  ENGINEERING,  SCIENTIFIC  AND  TECHNICAL  SKILLS 

The  relative  immaturity  of  both  management  and  technical  ECS  acquisition  and  support 
disciplines  results  in  a  short  supply  of  experienced  personnel.  Furthermore,  the  problem  is  an 
engineering  intensive  and  rapidly  moving  technology  based  area,  such  as  ECS  acquisition  and 
support.  Aggressively  implemented  education,  training,  retraining  and  cross-training  programs 
at  all  levels  on  a  continuing  basis  offers  an  opportunity  for  improvement. 

A.  10  OPTIMIZE  THE  COMPLIMENTARY  STRENGTHS  OF  ORGANIC  AND  CON¬ 
TRACTOR  SKILLS 

The  acquisition  and  life  cycle  support  of  ECS  offers  opportunities  for  a  wide  variety  of 
skills  and  disciplines.  Industry  has  traditionally  been  positioned  or  postured  to  perform  those 
tasks  that  the  government  has  chosen  not  to  do  because  of  mission  related  requirements,  or  for 
economic  or  other  reasons.  In  an  engineering  intensive  and  high  technology  area,  such  as  ECS 
acquisition  and  support,  direct  competition  for  scarce  highly  skilled  resources  will  benefit 
neither  government  nor  industry.  To  minimize  critical  organic  engineering,  scientific  and 
technical  skill  needs,  industry  provides  the  alternative  source.  The  industry  source  is  also  applic¬ 
able  in  those  cases  involving  acquisition/support  of  “one-of-a-kind”  or  shorter  duration,  highly 
specialize  activities  as  well  as  a  complementary  supplement  for  skill  needs  over  a  longer  period  of 
time.  Initial  acquis'tion/development  of  support  systems  and  augmentation  of  skiil  concentra¬ 
tions  are  also  areas  particularly  well  suited  and  aligned  with  industry  strengths. 

A.  1 1  ACCOMPLISH  EFFICIENT  AND  EFFECTIVE  ECS  SUPPORT  COST  ESTIMATING, 
TRACKING  AND  ACCOUNTING 

Management  and  engineering  disciplines  are  employed  in  determining  the  cost  of  acquisi¬ 
tion  and  ownership  of  ECS  support  systems.  The  separate  but  related  cost  functions  of 
estimating,  tracking  and  accounting  are  interdependent,  in  that  accurate  and  realistic  tracking 
and  accounting  ptovide  the  historical  data  base  for  future  estimates.  Cost  estimating,  which  is 
probably  the  most  difficult,  is  highly  dependent  upon  an  adequate  financial  and  engineering 
data  base.  The  structure  of  the  data  base,  along  with  the  tools  and  techniques  employed  for  data 
collection  and  use,  should  address  specific  systems  and  categories  as  well  as  the  ECS  support 
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system  acquisition  and  operation  and  maintenance  phases.  In  addition,  ail  activities  should  be  in 
concert  with  existing  financial  and  budget  requirements  and  cycles. 

A. 12  INFLUENCE  THE  PROLIFERATION  OF  ECS  AND  ECS  SUPPORT  SYSTFMS 
The  proliferation  of  ECS  and  their  attendant  support  systems  has  proceeded  during  the  past 
decade  without  apparent  limits.  This  combined  with  technologies  in  hand  and  those  on  the 
horizon  suggests  that  an  increased  deliberate  effort  will  be  needed  to  limit  the  introduction  of 
new  technology  applications  to  a  manageable  and  supportable  level.  A  planned  approach  for  the 
introduction  and  use  of  specific  technologies  is  necessary  in  conjunction  with  other  ongoing 
Department  of  Defense  and  service  programs,  such  as  the  use  of  military  standard  computers, 
and  adoption  of  the  preferred  DOD  computer  program  language.  Another  approach  to  slowing 
ECS  support  system  proliferation  without  impinging  on  technology  is  to  aggressively  pursue 
alternatives  to  the  general  practice  of  a  dedicated  one'  for  one  relationship  between  ECS  and 
ECS  Support  systems. 
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ECS  SUPPORT  REQUIREMENTS 

The  support  of  embedded  computer  systems  is  relatively  new  to  the  Air  Force  and  has  had  a 
significant  impact  on  the  Logistics  Command.  Support  responsibilities  and  requirements  have 
been  defined  at  a  top  level  but  a  co-;  .nsus  of  what  the  step-by-si  vp  requirements  are  has 
envolved  slowly.  During  Phase  11  of  the  study,  TRW  looked  closely  at  support  requirements  for 
the  five  ECS  categories  and  identified  support  requirements  that  were  common  to  all  categories 
and  those  that  were  unique  to  a  particular  category.  The  following  sr  ■  uential  listing  of  ECS  sup¬ 
port  requirements  drive  the  ECS  support  process  and  the  needed  viabilities  recommended  in 
the  long  range  ECS  support  plan. 

B.l  ECS  LIFE  CYCLE  SUPPORT  REQUIREMENTS 

ECS  support  life  cycle  responsibilities  of  AFLC  are  defined  by  AFR  800-14  and  AFLCR 
800-21  to  be  life  cycle  management,  system  engineering  and  training  of  support  personnel. 

B.1.1  Life  Cycle  Management 

AFLC  is  responsible  for  support  of  CRWG  activities,  which  include  a  coordinated  defini¬ 
tion  of  the  CRISP.  AFLC  is  also  responsible  for  development  of  an  O/S  CMP,  prior  to  PMRT. 
Following  PMRT,  they  are  responsible  for  management  of  the  weapon  system  and  its  support 
system. 

B.l. 2  System  Engineering 

AFLC  is  responsible  for  development  of  a  system  engineering  capability  prior  to  PMRT, 
and  for  using  this  capability  to  assist  in  support  system  definition.  After  PMRT,  they  are 
responsible  for  system  engineering  support  to  the  weapon  system  and  its  support  system. 

B.l. 3  Training 

AFLC  v.  responsible  for  training  its  weapon  system  support  personnel. 

B  2  PRE-PMRT  SUPPORT  REQUIREMENTS 

AFLC  is  responsible  prior  to  PMRT  for  establishment  of  a  support  posture.  This  includes 
identification  of  their  requirements  for  support  systems  to  the  CRWG,  and  training  of  personnel 
who  will  support  the  new  weapon  system  and  use  the  new  support  system.  Also  included  is  iden¬ 
tification  to  the  CRWG  of  support  criteria  affecting  the  system  design  (e.g  ,  standard  interfaces, 
languages,  etc.). 
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B.3  ECS  GENERIC  SUPPORT  REQUIREMENTS 

In  the  Phase  11  Baseline  Reports  of  the  ECS  Support  Study,  19  generic  ECS  support  activ¬ 
ities  were  identified.  These  19  activities  were  categorized  into  6  generic  ECS  support  require¬ 
ments. 

A  summary  of  these  generic  support  requirements  follows. 

B.3.1  ECS  Change 

The  ECS  change  management  requirement  is  composed  of  the  following  activities 

•  Receive  and  process  change  requests 

•  Perform  preliminary  analysis  and  problem/deficiency  definition 

•  Perform  preliminary  resource  allocation  and  scheduling 
B.3. 2  Change  Analysis  and  Specification 

This  ECS  change  requirement  is  fulfilled  by  the  following  set  of  engineering  activities, 
which  culminate  in  a  Computer  Program  Change  Proposal  (CPCP)  for  management  approval. 

•  Change  feasibility  analysis 

•  Requirements  definition/decomposition 

•  Preliminary  design 

•  Detailed  design 

•  Generate  computer  program  change  proposal 
B.3. 3  Engineering  Development  and  Unit  Test 

Following  approval  of  the  CPCP,  following  engineering  activities  are  performed. 

•  Develop  the  change 

•  Performed  unit  test 
B.3.4  System  Integration  and  Test 

After  the  module  level  changes  are  implemented  and  unit  tested,  the  following  activities  are 
performed  to  integrate  and  test  the  system 

•  Test  ECS  system  performance 

•  Test  weapon  system  performance 

•  Product  test  reports 


B.3.5  Change  Documentation 

All  implemented  changes,  minor  or  major,  must  be  reflected  in  the  system  documentation, 
and  the  configuration  management  activities  to  identify  and  control  the  system  and  its  documen¬ 
tation  performed.  The  activities  necessary  to  fulfill  this  requirement  are 

•  Document  the  ECS  Change 

•  Update  the  ECS  Baseline 

•  Configuration  Management 

B.3.6  Certification  and  Distribution 

A  central  point  should  exist  within  the  System  Manager’s  (SM)  Office  who  has  authority 
for  the  following  activities 

•  Certify  the  change  and  its  documentation 

•  Distribute  revised  ECS  data 

•  Provide  installation  procedures/instructions 

B.4  ECS  CATEGORY  UNIQUE  SUPPORT  REQUIREMENTS 

Support  requirements  which  are  unique  to  certain  categories  of  ECS  are  summarized  in  the 
following  subsections  and  in  Table  2-1.  These  category-unique  support  requirements  are 
presented  in  more  detail  in  the  ECS  Study  Baseline  Reports  (Volumes  III  through  VII). 

B.4. 1  Concurrency  (ATP  Category) 

The  configurations  of  the  primary  weapon  systemand  the  ATD  must  be  closely 
synchronized  to  provide  valid  training  on  the  ATD.  AFR  57-4  states,  “Trainer  modifications 
should  lead  the  weapon  system  modifications  by  at  least  90  days...”  without  delaying  the 
weapon  system  modification  release. 

B.4. 2  Shared  Software  Support  (ATD  and  C-E  Categories) 

With  modifications  developed  by  the  user  teams  or  by  contractor  under  AFLC  control, 
more  complex  interagency  coordination  and  configuration  control  is  required  to  ensure  a  correct 
definition  of  contractual  baselines,  to  ensure  that  the  user  support  team  has  a  knowledge  of  the 
'  LC’s  contractual  activities,  and  to  ensure  that  the  ALC  has,  at  all  times,  correct  baseline 
•imentation. 
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B.4.3  Intelligence  Support  (ATP,  C-E,  EW,  and  OFP  Categories) 

There  is  a  growing  trend  to  use  embedded  computers  to  give  weapon  systems  a  rapid  con¬ 
figuration  change  capability.  In  the  past  the  need  for  rapid  changes  in  ECS  software  was  limited 
to  EW  and  ATD  systems.  However,  the  introduction  of  the  Command  Control  Communica¬ 
tions  Countermeasures  (C3CM)  programs  will  generate  new  ECS  software  change  requirements, 
in  addition  to  generating  a  host  of  new  support  problems.  Most  of  the  data  needed  to  make 
C3CM  ECS  software  changes  is  classified  secret  or  higher.  In  some  case  the  supporting  and 
background  data  required  by  the  decision  making  process  (technical  assessments)  is  top  secret  or 
requires  compartmented  access. 

B.4.4  Rapid  Reprogramming  (C-E,  EW,  and  OFP  Categories) 

A  dynamic  threat  environment  exists  in  several  areas  of  the  world  resulting  in  changing 
requirements  for  system  capabilities.  These  urgent,  multiple  changes  may  simultaneously  apply 
to  more  than  one  system,  thus  demanding  a  rapid  reprogramming  respc 

B.4.5  Respond  to  Frequent  Change  Requests  (EW  Category) 

EW  technology  is  constantly  changing.  This,  coupled  with  a  dynamic  threat  environment, 
causes  EW  system  change  requests  at  a  higher  frequency  than  the  development  responses  to  the 
changes.  Consequently,  there  is  a  tendency  for  changes  to  compound  each  other. 

B.4.6  Nuclear  Safety  Criteria  (OFP  Category) 

Embedded  computer  systems  that  have  a  first  or  second  level  interface  to  a  nuclear  weapon 
as  defined  in  AFR  122-9  fall  in  a  special  category  with  specific  design  and  test  requirements.  This 
includes  software  used  by  automata  which  control  critical  functions  of  a  nuclear  veapon  (first 
level  interface)  or  which  respond  10  or  transmit  information  to  automata  having  a  first  level 
interface. 


APPENDIX  C 

SUMMARY  OF  BASELINE  SUPPORT  DEFICIENCIES 

Current  support  deficiencies  for  the  ATD,  ATE,  C-E,  EW,  and  OFP  categories  were  col¬ 
lected/summarized  from  the  Embedded  Computer  System  Study  Phase  II  Report  (Volumes  III- 
VII).  These  summary  deficiencies  are  presented  in  Tables  C-l  through  C-5,  along  with  proposed 
corrective  actions  to  resolve  the  deficiencies.  The  corrective  actions  are  embodied  in  the  recom¬ 
mended  administrative  and  programmatic  initiatives  contained  in  the  long  rar.je  ECS  support 
plan. 


Table  C-l.  ATD  Support  Deficiencies  Versus  Requirements 


Table  C-l.  ATD  Support  Deficiencies  Versus  Requirements  (Continued) 
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Table  C-l.  ATD  Support  Deficiencies  Versus  Requirements  (Continued) 


Table  C-l.  ATD  Support  Deficiencies  Versus  Requirements  (Concluded) 


Table  C-2.  ATE  Support  Deficiencies  Versus  Requirements 
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Table  C-2.  ATE  Support  Deficiencies  Versus  Requirements  (Continued) 
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Table  C-2.  ATE  Support  Deficiencies  Versus  Requirements  ( Concluded ) 
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Table  C-3.  C-E  Support  Deficiencies  Versus  Requirements  (Continued) 


Table  C-3.  C-E  Support  Deficiencies  Versus  Requirements  (Concluded) 
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able  C-*  EW  Support  Deficiencies  Versus  Requirements  (Continued) 


Change  Documentation  •  Incomplete  documentation  •  Automated  documentation  tools 


Slow  change  process  via  using  |  •  Develop  alternative  method  to 

TCTOs  TCTOs  for  software  changes 
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Table  C-5.  OFP  Support  Deficiencies  Versus  Requirements 
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EISF  CONCEPT  APPLIED  TO  GROUND  EW  SYSTEMS 

The  extendable  integration  support  facility  (EISF)  concept  presented  in  Section  4.2  was 
developed  to  satisfy  a  wide  variety  of  embedded  computer  system  support  needs.  This  appendix 
illustrates  how  this  concept  could  be  applied  to  a  ground  EW  1SF  by  incorporating  the  current 
investment  and  with  minimum  impact  on  the  current  ISF  design.  Table  D-l  lists  the  ground  EW 
systems  which  are  operational  or  will  PMRT  in  the  next  three  years.  The  ISF  network  shown  in 
Figure  D-l  accommodates  these  systems  and  could  serve  as  a  model  for  a  more  definitive  proto¬ 
type  design.  All  of  the  systems  shown  in  Figure  D-l,  enclosed  in  solid  symbols,  are  currently  in 
place  except  for  the  Network  Interface  Units  (NIU)  and  additional  INTEL  microprocessor 
development  system  (MDS),  which  host  the  hardware  simulation  kernels.  Work  is  in  process  at 
SM-ALC  on  Simulation  Kernel  design,  however,  only  one  prototype  has  been  started.  The  effi¬ 
ciency  of  this  ISF  architecture  could  be  improved  by  adding  a  communications  network  and 
sharing  of  peripheral  systems. 

The  network  interface  unit  shown  in  Figure  D-2  and  its  associated  network  communication 
protocols  have  not  been  designed  beyong  the  conceptual  level.  Additional  engineering  design 
and  software  development  are  required  prior  to  building  the  EISF  prototype.  In  addition  to 
development  of  the  communications  software,  a  multiprocessor/multiuser  operating  system 
must  be  developed  or  adapted  from  commercially  available  software.  This  software  and  the  NIU 
design  and  support  software  are  crucial  components  and  are  prototype  development  pacing 
items.  However,  with  a  decision  to  develop  ECS  support  networks,  the  design  of  protocols 
which  are  compatible  with  both  long  haul  and  local  netwoiks  may  become  the  pacing  item. 

Once  a  standard  work  station  has  been  specified,  designed,  and  built,  the  S-100  work  sta¬ 
tions,  shown  in  this  example,  should  be  re'  'aced.  The  development  of  a  standard  work  station 
prototype  could  be  developed  as  a  separate  project  of  as  a  total  development  package  for  even¬ 
tual  use  in  other  ISF’s. 
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Table  D-l.  Ground  EW  Systems  (ECS  Support  Required) 


Title 

De  signation 

PM  R  T 

Host 

EW  Range 

Radar  System 

MPS-T1 

OPER 

Motorola  68000 

Tactical  Radar 
Threat  Generator 

TRTG 

4/80 

Motorola  6800 

AAA  Radar 

Simulator 

MPQ-T3 

2/81 

NOVA  -4 

Multiple  Threat 
Emitter  System 

MST-T1A 

3/81 

Eclipse  S130 

Multiple  Receiver 
Analysis  System 

MSR-T1 

3/82 

HP-1000F(2) 

Modular  Threat 
Emitter 

MTE 

2/83 

NOVA  4 

Ground  Jammer 

MLQ-T4 

3/83 

LSI  11/23 
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The  network  interface  unit  shown  in  Figure  D-2  and  its  associated 
network  communication  protocols  have  not  been  designed  beyond  the  con¬ 
ceptual  level.  Additional  engineering  design  and  software  development 
are  required  prior  to  building  the  EISF  prototype.  In  addition  to  develop¬ 
ment  of  the  communications  software,  a  multiprocessor /multiuser  oper¬ 
ating  system  must  be  developed  or  adapted  from  commercially  available 
software.  This  software  and  the  NIU  design  and  support  software  are 
crucial  components  and  are  prototype  development  pacing  items.  How¬ 
ever,  with  a  decision  to  develop  FCS  support  networks,  the  design  of 
protocols  which  are  compatible  with  both  long  haul  and  local  networks 
may  become  the  pacing  item. 

Once  a  standard  work  station  has  been  specified,  designed  and 
built,  the  S- 100  work  stations,  shown  in  this  example,  should  be 
replaced,  The  development  of  a  standard  work  station  prototype  could 
be  developed  as  a  separate  project  or  as  a  total  development  package  for 
eventual  use  in  other  ISF's. 
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